Messages in this thread | | | Date | Tue, 18 Dec 2012 16:22:18 -0600 | Subject | Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value | From | Will Drewry <> |
| |
Thanks for the patch!
On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant <coreyb@linux.vnet.ibm.com> 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 :)
[snip] > 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; > + case SECCOMP_RET_INFO: > + 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.
Thanks! will
| |