lkml.org 
[lkml]   [2017]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v3 0/4] Improved seccomp logging
    From
    Date
    On 04/27/2017 07:42 PM, Kees Cook wrote:
    > On Thu, Apr 27, 2017 at 3:17 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
    >> Quick update... I finished the move from the high-water mark
    >> log_max_action sysctl to the bitmask based actions_logged sysctl.
    >
    > Awesome!
    >
    >> Unfortunately, I've just realized that SECCOMP_SET_LOGGING, or any
    >> process-wide logging configuration mechanism, will not work. It is fine
    >> for the situation where two unrelated processes set up seccomp filters
    >> that should be logged differently. However, it fails when two closely
    >> related processes, such as parent and child, need to set up seccomp
    >> filters that should be logged differently. Imagine a launcher that sets
    >> up an application sandbox (including a seccomp filter) and then launches
    >> an electron app which will have its own seccomp filter for sandboxing
    >> untrusted code that it runs. Unless the launcher and app completely
    >> agree on actions that should be logged, the logging won't work as
    >> intended for both processes.
    >
    > Oh, you mean the forked process sets up the logging it wants for the
    > filters it just installed, then after exec a process sets up new
    > logging requirements?

    Yes - see below.

    >
    >> I think this needs to be configured at the filter level.
    >
    > I'm not sure that's even the right way to compose the logging desires.
    >
    > So, my initial thought was "whatever ran SECCOMP_SET_LOGGING knows
    > what it's doing" and it should be the actual value.
    >
    > If the launcher wants logs of everything the application does with its
    > filters, then a purely-tied-to-filter approach won't work either.
    >
    > Perhaps log bits can only be enabled? I.e. SECCOMP_SET_LOGGING
    > performs an OR instead of an assignment?

    The problem that I'm envisioning with this design is this:

    1. Launcher is told to launch Chrome and forks off a process.

    2. Launcher sets up a filter using RET_ERRNO for all unacceptable
    syscalls and enables auditing of RET_ERRNO.

    3. Launcher execs Chrome.

    4. Chrome then sets up its own, more restrictive filter that uses
    RET_ERRNO, among other actions, but does not want auditing of RET_ERRNO.

    If we use process-wide auditing controls, the logs will be filled with
    RET_ERRNO messages that were unintended and unrelated to the RET_ERRNO
    actions set up in the launcher's filter.

    Unfortunately, the OR'ing idea doesn't solve the problem.

    Tyler

    >
    > -Kees
    >

    \
     
     \ /
      Last update: 2017-05-02 04:42    [W:5.351 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site