Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Paul Moore <pmoore@redhat.com>]

On Wednesday, December 19, 2012 09:56:13 AM Corey Bryant wrote:
> On 12/18/2012 05:22 PM, Will Drewry wrote:
> > while others I've spoken with have been using the audit path to track
> > denied values -- not so great for soft-failures :)
> 
> The audit path would work too but if I understand I think you can only
> learn one syscall per execution.  The nice thing about SECCOMP_RET_INFO
> is that you can easily learn all the syscalls in one execution.

Another quick point about the audit log: on some systems, e.g. tightly secured 
SELinux systems, the audit log is only accessible via a very privileged user 
(Will hints at this below).  Normal users do not have access to, and therefore 
can't make use of, the seccomp related audit records.

> > That aside, I worry that pr_info is the wrong place for a random user
> > on the machine to log to for this, but I may be wrong, rather than a
> > dedicated ringbufffer, etc.  So if this is for a user with privs, then
> > a SECCOMP_RET_AUDIT might make sense.  Feedback to a local user seems
> > tricky in general. I don't know :)  I just decided to deal with it in
> > userland even if it is slightly painful.
> 
> That's a good point.  I don't know which option is better either so if
> anyone else could weigh in on the better approach I'd appreciate it.

I agree with Will's statement about better to deal with the problem in 
userspace when possible, but as Corey pointed out, our experiences with QEMU 
have demonstrated that dealing with the problem exclusively in userspace just 
isn't practical in every case.

Syslog might not be the answer, but RET_TRAP and the audit log aren't very 
good answers either.

-- 
paul moore
security and virtualization @ redhat