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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Feb 2017 15:29:19 -0800
From:   Kees Cook <>
To:     Andy Lutomirski <>
Cc:     Tyler Hicks <>,
        Paul Moore <>,
        Eric Paris <>, Will Drewry <>,,
        "" <>,
        John Crispin <>,
Subject: Re: [PATCH v3 0/4] Improved seccomp logging

On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <> wrote:
> On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <> wrote:
>> This patch set is the third revision of the following two previously
>> submitted patch sets:
>> v1:
>> v1:
>> v2:
>> The patch set aims to address some known deficiencies in seccomp's current
>> logging capabilities:
>>   1. Inability to log all filter actions.
>>   2. Inability to selectively enable filtering; e.g. devs want noisy logging,
>>      users want relative quiet.
>>   3. Consistent behavior with audit enabled and disabled.
>>   4. Inability to easily develop a filter due to the lack of a
>>      permissive/complain mode.
> I think I dislike this, but I think my dislikes may be fixable with
> minor changes.
> What I dislike is that this mixes app-specific built-in configuration
> (seccomp) with global privileged stuff (audit).  The result is a
> potentially difficult to use situation in which you need to modify an
> app to make it loggable (using RET_LOG) and then fiddle with
> privileged config (auditctl, etc) to actually see the logs.

You make a good point about RET_LOG vs log_max_action. I think making
RET_LOG the default value would work for 99% of the cases.

> What if, instead of logging straight to the audit log, SECCOMP_RET_LOG
> [1] merely meant "tell our parent about this syscall"?  (Ideally we'd
> also figure out a way to express "log this and allow", "log this and
> do ERRNO", etc.)  Then we could have another mechanism that installs a
> layer in the seccomp stack that, instead of catching syscalls, catches
> log events and sticks them in a ring buffer (or audit).

So, I really don't like this because it's yet another logging system.
We already have a security event logger: audit. This continues to use
that subsystem without changing semantics very much.

> Concretely, it might work like this.  If a filter returns
> SECCOMP_RET_LOG, then we "log" and keep processing.  SECCOMP_RET_LOG
> is otherwise treated literally like SECCOMP_RET_ALLOW and has no
> effect on return value.  If you want log-and-kill, you install two
> filters.
> There's a new seccomp(2) action that returns an fd.  That fd
> references a new thing in the seccomp stack that is a BPF program that
> is called whenever SECCOMP_RET_LOG is returned from lower down.  The
> output of this filter determines whether the log event is ignored,
> stuck in the ring buffer, or passed up the stack for further
> processing.  You read(2) the fd to access the ring buffer.
> Using this mechanism, you could write a simple seccomptrace tool that
> needs no privilege and dumps SECCOMP_RET_LOG events from the target
> program to stderr.

If someone was going to do this, they could just as well set up a
tracer to use RET_TRAP. (And this is what things like minijail does
already, IIRC.) The reality of the situation is that this is way too
much overhead for the common case. We need a generalized logging
system that uses the existing logging mechanisms.

> Thoughts?
> [1] If we went this route, it might want to be renamed.
> P.S. We ought to be able to write a BPF verifier pass that makes sure
> that filters don't return unsupported return values if we cared to do
> so.

Can we? I thought the BPF_RET used the BPF registers, and validating
that might be less-than-easy?


Kees Cook
Pixel Security

Powered by blists - more mailing lists