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 <>
To:	Corey Bryant <>
	Kees Cook <>
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 <> 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;
> +               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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists