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

From: Will Drewry
Date: Tue Dec 18 2012 - 17:30:11 EST

Thanks for the patch!

On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant <coreyb@xxxxxxxxxxxxxxxxxx> wrote:
> Adds a new return value to seccomp filters that causes an
> informational kernel message to be printed. The message
> includes the system call number.

I don't have strong opinions about this either way, but here are the
points that led me to drop a _LOG return value in the past:
- ptrace can cover this awkwardly (user)
- ftrace can cover this awkwardly (system/root)
- audit can cover this without an allow
- _TRAP can be used to implement this
- There's no good way to give back the log data.

I've been relying on SECCOMP_RET_TRAP:
- trap on failure, log, then die
- trap on failure, log, then jump to a whitelisted re-entry point to
resume the syscall
while others I've spoken with have been using the audit path to track
denied values -- not so great for soft-failures :)

> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 5af44b5..854f628 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -433,6 +433,10 @@ int __secure_computing(int this_syscall)
> goto skip; /* Explicit request to skip. */
> return 0;
> + if (printk_ratelimit())
> + pr_info("seccomp: syscall=%d\n", this_syscall);

The arch value will also be needed to make this reliably meaningful
(how was the syscall called).

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.

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