lkml.org 
[lkml]   [2015]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: v5 of seccomp filter c/r patches
    From
    On Fri, Oct 2, 2015 at 2:29 PM, Andy Lutomirski <luto@amacapital.net> wrote:
    > On Fri, Oct 2, 2015 at 2:10 PM, Kees Cook <keescook@chromium.org> wrote:
    >> On Fri, Oct 2, 2015 at 9:27 AM, Tycho Andersen
    >> <tycho.andersen@canonical.com> wrote:
    >>> Hi all,
    >>>
    >>> Here's v5 of the seccomp filter c/r set. The individual patch notes have
    >>> changes, but two highlights are:
    >>>
    >>> * This series is now based on http://patchwork.ozlabs.org/patch/525492/ and
    >>> will need to be built with that patch applied. This gets rid of two incorrect
    >>> patches in the previous series and is a nicer API.
    >>>
    >>> * I couldn't figure out a nice way to have SECCOMP_GET_FILTER_FD return the
    >>> same struct file across calls, so we still need a kcmp command. I've narrowed
    >>> the scope of the one being added to only compare seccomp fds.
    >>>
    >>> Thoughts welcome,
    >>
    >> Hi, sorry I've been slow/busy. I'm finally reading through these threads.
    >>
    >> Happy bit:
    >> - avoiding eBPF and just saving the original filters makes things much easier.
    >>
    >> Sad bit:
    >> - inventing a new interface for seccompfds feels like massive overkill to me.
    >>
    >> While Andy has big dreams, we're not presently doing seccompfd
    >> monitoring, etc. There's no driving user for that kind of interface,
    >> and accepting the maintenance burden of it only for CRIU seems unwise.
    >>
    >> So, I'll go back to what I originally proposed at LSS (which it looks
    >> like we're half way there now):
    >>
    >> - save the original filter (done!)
    >> - extract filters through a single special-purpose interface (looks
    >> like ptrace is the way to go: root-only, stopped process, etc)
    >> - compare filter content and issue TSYNCs to merge detected sibling
    >> threads, since merging things that weren't merged before creates no
    >> problems.
    >>
    >> This means the parenting logic is heuristic, but it's entirely in
    >> userspace, so the complexity burden doesn't live in seccomp which we,
    >> by design, want to keep as simple as possible.
    >
    > This is okay with me with a future-proofing caveat: I think that
    > whatever reads out the filter should be clearly documented as
    > returning some special error code that indicates that that filter it
    > tried to read wasn't in the expected form. That would happen for
    > native eBPF filters, and it would also happen for seccomp monitors
    > even if those monitors use classic BPF.

    As in, it should have something like "give me BPF" and that'll start
    failing when it's only eBPF in the future?

    -Kees

    --
    Kees Cook
    Chrome OS Security


    \
     
     \ /
      Last update: 2015-10-03 00:21    [W:2.790 / U:0.748 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site