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

[Will Drewry]

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 :)

[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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/