Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1238622

Re: v5 of seccomp filter c/r patches

From Kees Cook <keescook@chromium.org>
Newsgroups linux.kernel
Subject Re: v5 of seccomp filter c/r patches
Date 2015-10-02 23:20 +0200
Message-ID <qffUd-6LS-1@gated-at.bofh.it> (permalink)
References <qfbnA-cS-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

v5 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-10-02 18:30 +0200
  Re: v5 of seccomp filter c/r patches Kees Cook <keescook@chromium.org> - 2015-10-02 23:20 +0200
    Re: v5 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-10-02 23:40 +0200
      Re: v5 of seccomp filter c/r patches Kees Cook <keescook@chromium.org> - 2015-10-03 00:10 +0200
        Re: v5 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-10-03 00:20 +0200
      Re: v5 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-10-03 00:10 +0200
      Re: v5 of seccomp filter c/r patches Kees Cook <keescook@chromium.org> - 2015-10-03 00:10 +0200
    Re: v5 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-10-03 00:50 +0200
      Re: v5 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-10-03 01:00 +0200
      Re: v5 of seccomp filter c/r patches Daniel Borkmann <daniel@iogearbox.net> - 2015-10-03 01:00 +0200
        Re: v5 of seccomp filter c/r patches Tycho Andersen <tycho.andersen@canonical.com> - 2015-10-03 01:00 +0200
        Re: v5 of seccomp filter c/r patches Kees Cook <keescook@chromium.org> - 2015-10-03 01:10 +0200
      Re: v5 of seccomp filter c/r patches Andy Lutomirski <luto@amacapital.net> - 2015-10-03 01:00 +0200

csiph-web