From: Will Drewry <wad@chromium.org>
To: "Serge E. Hallyn" <serge.hallyn@canonical.com>
Cc: linux-kernel@vger.kernel.org, keescook@chromium.org,
john.johansen@canonical.com, coreyb@linux.vnet.ibm.com,
pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org,
torvalds@linux-foundation.org, segoon@openwall.com,
rostedt@goodmis.org, jmorris@namei.org, scarybeasts@gmail.com,
avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk,
luto@mit.edu, mingo@elte.hu, akpm@linux-foundation.org,
khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com,
oleg@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com,
gregkh@suse.de, dhowells@redhat.com, daniel.lezcano@free.fr,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, olofj@chromium.org,
mhalcrow@google.com, dlaor@redhat.com, corbet@lwn.net,
alan@lxorguk.ukuu.org.uk, indan@nul.nu, mcgrathr@chromium.org
Subject: Re: [PATCH v6 2/3] seccomp_filters: system call filtering using BPF
Date: Fri, 3 Feb 2012 15:14:52 -0800 [thread overview]
Message-ID: <CABqD9hZ7bckPj+cCC-thGz2eu9iF-psX1EckpAmM6jivneFypA@mail.gmail.com> (raw)
In-Reply-To: <20120202153232.GB4583@sergelap>
On Thu, Feb 2, 2012 at 7:32 AM, Serge E. Hallyn
<serge.hallyn@canonical.com> wrote:
> Quoting Will Drewry (wad@chromium.org):
>> [This patch depends on luto@mit.edu's no_new_privs patch:
>> https://lkml.org/lkml/2012/1/12/446
>> ]
>>
>> This patch adds support for seccomp mode 2. This mode enables dynamic
>> enforcement of system call filtering policy in the kernel as specified
>> by a userland task. The policy is expressed in terms of a Berkeley
>> Packet Filter program, as is used for userland-exposed socket filtering.
>> Instead of network data, the BPF program is evaluated over struct
>> seccomp_filter_data at the time of the system call.
>>
>> A filter program may be installed by a userland task by calling
>> prctl(PR_ATTACH_SECCOMP_FILTER, &fprog);
>> where fprog is of type struct sock_fprog.
>>
>> If the first filter program allows subsequent prctl(2) calls, then
>> additional filter programs may be attached. All attached programs
>> must be evaluated before a system call will be allowed to proceed.
>>
>> To avoid CONFIG_COMPAT related landmines, once a filter program is
>> installed using specific is_compat_task() value, it is not allowed to
>> make system calls using the alternate entry point.
>>
>> Filter programs will be inherited across fork/clone and execve, however
>> the installation of filters must be preceded by setting 'no_new_privs'
>> to ensure that unprivileged tasks cannot attach filters that affect
>> privileged tasks (e.g., setuid binary). Tasks with CAP_SYS_ADMIN
>> in their namespace may install inheritable filters without setting
>> the no_new_privs bit.
>>
>> There are a number of benefits to this approach. A few of which are
>> as follows:
>> - BPF has been exposed to userland for a long time.
>> - Userland already knows its ABI: system call numbers and desired
>> arguments
>> - No time-of-check-time-of-use vulnerable data accesses are possible.
>> - system call arguments are loaded on demand only to minimize copying
>> required for system call number-only policy decisions.
>>
>> This patch includes its own BPF evaluator, but relies on the
>> net/core/filter.c BPF checking code. It is possible to share
>> evaluators, but the performance sensitive nature of the network
>> filtering path makes it an iterative optimization which (I think :) can
>> be tackled separately via separate patchsets. (And at some point sharing
>> BPF JIT code!)
>>
>> v6: - fix memory leak on attach compat check failure
>> - require no_new_privs || CAP_SYS_ADMIN prior to filter
>> installation. (luto@mit.edu)
>> - s/seccomp_struct_/seccomp_/ for macros/functions
>> (amwang@redhat.com)
>> - cleaned up Kconfig (amwang@redhat.com)
>> - on block, note if the call was compat (so the # means something)
>> v5: - uses syscall_get_arguments
>> (indan@nul.nu,oleg@redhat.com, mcgrathr@chromium.org)
>> - uses union-based arg storage with hi/lo struct to
>> handle endianness. Compromises between the two alternate
>> proposals to minimize extra arg shuffling and account for
>> endianness assuming userspace uses offsetof().
>> (mcgrathr@chromium.org, indan@nul.nu)
>> - update Kconfig description
>> - add include/seccomp_filter.h and add its installation
>> - (naive) on-demand syscall argument loading
>> - drop seccomp_t (eparis@redhat.com)
>> v4: - adjusted prctl to make room for PR_[SG]ET_NO_NEW_PRIVS
>> - now uses current->no_new_privs
>> (luto@mit.edu,torvalds@linux-foundation.com)
>> - assign names to seccomp modes (rdunlap@xenotime.net)
>> - fix style issues (rdunlap@xenotime.net)
>> - reworded Kconfig entry (rdunlap@xenotime.net)
>> v3: - macros to inline (oleg@redhat.com)
>> - init_task behavior fixed (oleg@redhat.com)
>> - drop creator entry and extra NULL check (oleg@redhat.com)
>> - alloc returns -EINVAL on bad sizing (serge.hallyn@canonical.com)
>> - adds tentative use of "always_unprivileged" as per
>> torvalds@linux-foundation.org and luto@mit.edu
>> v2: - (patch 2 only)
>>
>> Signed-off-by: Will Drewry <wad@chromium.org>
>
> Hi Will,
>
> as far as I can tell based on changelog I suspect you could have
> kept my Acked-by (from v3?). However, I'll wait until your next
> submission (as I see there were a few change requests), and do a
> final complete new review of that.
Thanks, Serge! I just failed at the proper protocol and didn't mean
to not include your Acked-by. However, I am changing a fair amount
of the internals this time around, so I'll be happy to have another
full review.
> Thanks for continuing to push on this.
Definitely! I've been traveling this week, so it's been a bit slow
going, but I hope to have the next rev up early next week if not
sooner.
Cheers!
will
next prev parent reply other threads:[~2012-02-03 23:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-28 22:11 [PATCH v6 1/3] seccomp: kill the seccomp_t typedef Will Drewry
2012-01-28 22:11 ` [PATCH v6 2/3] seccomp_filters: system call filtering using BPF Will Drewry
2012-01-31 14:13 ` Eduardo Otubo
2012-01-31 15:20 ` Will Drewry
2012-02-02 15:32 ` Serge E. Hallyn
2012-02-03 23:14 ` Will Drewry [this message]
2012-01-28 22:11 ` [PATCH v6 3/3] Documentation: prctl/seccomp_filter Will Drewry
2012-01-30 22:47 ` Corey Bryant
2012-01-30 22:52 ` Will Drewry
2012-02-02 15:29 ` [PATCH v6 1/3] seccomp: kill the seccomp_t typedef Serge E. Hallyn
2012-02-03 23:16 ` Will Drewry
2012-02-04 1:05 ` Linus Torvalds
2012-02-06 16:13 ` Will Drewry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABqD9hZ7bckPj+cCC-thGz2eu9iF-psX1EckpAmM6jivneFypA@mail.gmail.com \
--to=wad@chromium.org \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=amwang@redhat.com \
--cc=avi@redhat.com \
--cc=borislav.petkov@amd.com \
--cc=corbet@lwn.net \
--cc=coreyb@linux.vnet.ibm.com \
--cc=daniel.lezcano@free.fr \
--cc=dhowells@redhat.com \
--cc=djm@mindrot.org \
--cc=dlaor@redhat.com \
--cc=eparis@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=gregkh@suse.de \
--cc=indan@nul.nu \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=khilman@ti.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@mit.edu \
--cc=mcgrathr@chromium.org \
--cc=mhalcrow@google.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=olofj@chromium.org \
--cc=penberg@cs.helsinki.fi \
--cc=pmoore@redhat.com \
--cc=rostedt@goodmis.org \
--cc=scarybeasts@gmail.com \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).