linux-kernel - Re: [PATCH 1/3] seccomp: Add SECCOMP_RET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Dec 2012 16:22:18 -0600
From:	Will Drewry <wad@...omium.org>
To:	Corey Bryant <coreyb@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org,
	pmoore@...hat.com, otubo@...ux.vnet.ibm.com,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

Thanks for the patch!

On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant <coreyb@...ux.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/