APPLIED: [Precise][Pull Request] SECCOMP mode 2, BPF

Will Drewry wad at
Thu Mar 22 18:43:57 UTC 2012

On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner <tim.gardner at> wrote:
> On 03/21/2012 02:35 PM, Kees Cook wrote:
>> On Wed, Mar 21, 2012 at 02:28:33PM -0600, Tim Gardner wrote:
>>> Applied for now pending Leann's opinion. I've made a first pass review.
>>> Some of it is a bit dense. I'll have another look tomorrow.
>> Thanks! I'm happy to field any questions about it, if that helps, and
>> if I can't answer them, I'm sure Will can. :)
>> -Kees
> So I guess it got uploaded. How about a quick description of how to
> utilize the seccomp filter?

Like this?  Or more like a usecase or a code snippet?
Seccomp filter allows a task to dynamically filter system calls for
itself and any subsequently spawned subtasks.  The behavior is
expressed in terms of a Berkeley Packet Filter program which is passed
to the kernel using prctl(2).

BPF programs may be built using macros from <linux/filter.h> and
execute over the virtual data structure described in

A filtered system call may be allowed to executed, denied with process
death, denied with an errno, denied with a SIGSYS signal, or passed to
an attached ptrace(2)er.  The action is dictated by the return code
from the BPF program.

There's also an effort we're not involved in to provide a pretty
full-featured library:

We'll be pulling support into our minijail application, but right now
it lives in a sandbox branch.

> Does the chromium browser detect and make
> use of seccomp automatically ?

Not yet, but it will.  I postponed integrating the original
seccomp+ftrace sandbox once I realized it was doomed to be out-of-tree
forever.  There'll likely be two seccomp sandboxes:
- generic seccomp bpf sandbox which will detect seccomp mode 2 support
and optionally layer with the setuid sandbox
  (easiest way to detect is prctl(PR_SET_SECCOMP, 2, NULL) -> -EFAULT
instead of -EINVAL)
- extended to use seccomp bpf.
markus at will be working on this, but I'm not sure if it
will go on by default later or not.

If all goes well, we should see the first one merge in less than six weeks.

> How can we test that its doing what is
> supposed to ?

samples/seccomp provide some baseline examples.  I'm out on vacation,
but I'll publish a small testsuite next week which I've been using to
test each rev.  I just need to pretty-it-up a bit :/

> In the meantime I guess I'll go read the seccomp patch to the
> Documentation directory.

If the docs can be made more coherent, I'm more than happy to change them up.


More information about the kernel-team mailing list