Thanks for the patch!
On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant <cor...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
