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

From: Paul Moore
Date: Wed Dec 19 2012 - 10:28:42 EST

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at