lkml.org 
[lkml]   [2017]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 0/4] Improved seccomp logging
    On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <luto@amacapital.net> wrote:
    > On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
    >> This patch set is the third revision of the following two previously
    >> submitted patch sets:
    >>
    >> v1: http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhicks@canonical.com
    >> v1: http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhicks@canonical.com
    >>
    >> v2: http://lkml.kernel.org/r/1486100262-32391-1-git-send-email-tyhicks@canonical.com
    >>
    >> 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

    --
    Kees Cook
    Pixel Security

    \
     
     \ /
      Last update: 2017-02-17 00:29    [W:4.308 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site