Patchwork [Precise,Pull,Request] SECCOMP mode 2, BPF

login
register
mail settings
Submitter Kees Cook
Date March 21, 2012, 7:18 p.m.
Message ID <20120321191804.GR4432@outflux.net>
Download mbox
Permalink /patch/148064/
State New
Headers show

Pull-request

git://github.com/kees/linux.git ubuntu-precise

Comments

Kees Cook - March 21, 2012, 7:18 p.m.
The following changes since commit b0c18ca93ec9fec352594a5a1ab16c3aec131f96:
  Leann Ogasawara (1):
        UBUNTU: Ubuntu-3.2.0-19.31

are available in the git repository at:

  git://github.com/kees/linux.git ubuntu-precise

Andy Lutomirski (1):
      UBUNTU: SAUCE: SECCOMP: Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

Eric Paris (1):
      seccomp: audit abnormal end to a process due to seccomp

John Johansen (1):
      UBUNTU: SAUCE: SECCOMP: Fix apparmor for PR_{GET,SET}_NO_NEW_PRIVS

Kees Cook (2):
      UBUNTU: SAUCE: SECCOMP: seccomp: remove duplicated failure logging
      UBUNTU: [Config] SECCOMP_FILTER=y

Will Drewry (12):
      UBUNTU: SAUCE: SECCOMP: sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W
      UBUNTU: SAUCE: SECCOMP: net/compat.c,linux/filter.h: share compat_sock_fprog
      UBUNTU: SAUCE: SECCOMP: seccomp: kill the seccomp_t typedef
      UBUNTU: SAUCE: SECCOMP: arch/x86: add syscall_get_arch to syscall.h
      UBUNTU: SAUCE: SECCOMP: asm/syscall.h: add syscall_get_arch
      UBUNTU: SAUCE: SECCOMP: seccomp: add system call filtering using BPF
      UBUNTU: SAUCE: SECCOMP: seccomp: add SECCOMP_RET_ERRNO
      UBUNTU: SAUCE: SECCOMP: signal, x86: add SIGSYS info and make it synchronous.
      UBUNTU: SAUCE: SECCOMP: seccomp: Add SECCOMP_RET_TRAP
      UBUNTU: SAUCE: SECCOMP: ptrace,seccomp: Add PTRACE_SECCOMP support
      UBUNTU: SAUCE: SECCOMP: x86: Enable HAVE_ARCH_SECCOMP_FILTER
      UBUNTU: SAUCE: SECCOMP: Documentation: prctl/seccomp_filter

 Documentation/prctl/seccomp_filter.txt         |  156 +++++++++
 arch/Kconfig                                   |   24 ++
 arch/x86/Kconfig                               |    1 +
 arch/x86/ia32/ia32_signal.c                    |    4 +
 arch/x86/include/asm/ia32.h                    |    6 +
 arch/x86/include/asm/syscall.h                 |   23 ++
 arch/x86/kernel/ptrace.c                       |    7 +-
 debian.master/config/amd64/config.common.amd64 |    1 +
 debian.master/config/enforce                   |    2 +-
 debian.master/config/i386/config.common.i386   |    1 +
 fs/exec.c                                      |   10 +-
 include/asm-generic/siginfo.h                  |   22 ++
 include/asm-generic/syscall.h                  |   14 +
 include/linux/Kbuild                           |    1 +
 include/linux/audit.h                          |    8 +
 include/linux/filter.h                         |   12 +
 include/linux/prctl.h                          |   15 +
 include/linux/ptrace.h                         |    7 +-
 include/linux/sched.h                          |    4 +-
 include/linux/seccomp.h                        |  105 +++++-
 include/linux/security.h                       |    1 +
 kernel/auditsc.c                               |   58 ++--
 kernel/fork.c                                  |    3 +
 kernel/ptrace.c                                |    3 +
 kernel/seccomp.c                               |  446 +++++++++++++++++++++++-
 kernel/signal.c                                |    9 +-
 kernel/sys.c                                   |   12 +-
 net/compat.c                                   |    8 -
 net/core/filter.c                              |    6 +
 samples/Makefile                               |    2 +-
 samples/seccomp/Makefile                       |   38 ++
 samples/seccomp/bpf-direct.c                   |  176 ++++++++++
 samples/seccomp/bpf-fancy.c                    |  102 ++++++
 samples/seccomp/bpf-helper.c                   |   89 +++++
 samples/seccomp/bpf-helper.h                   |  238 +++++++++++++
 samples/seccomp/dropper.c                      |   68 ++++
 security/apparmor/domain.c                     |   35 ++
 security/commoncap.c                           |    7 +-
 security/selinux/hooks.c                       |   10 +-
 39 files changed, 1660 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/prctl/seccomp_filter.txt
 create mode 100644 samples/seccomp/Makefile
 create mode 100644 samples/seccomp/bpf-direct.c
 create mode 100644 samples/seccomp/bpf-fancy.c
 create mode 100644 samples/seccomp/bpf-helper.c
 create mode 100644 samples/seccomp/bpf-helper.h
 create mode 100644 samples/seccomp/dropper.c
Tim Gardner - March 21, 2012, 8:28 p.m.
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.

rtg
Kees Cook - March 21, 2012, 8:35 p.m.
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
Tim Gardner - March 22, 2012, 1:07 p.m.
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? Does the chromium browser detect and make
use of seccomp automatically ? How can we test that its doing what is
supposed to ?

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

rtg
Will Drewry - March 22, 2012, 6:43 p.m.
On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner <tim.gardner@canonical.com> 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
<linux/seccomp.h>.

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: http://sourceforge.net/projects/libseccomp/

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)
- code.google.com/p/seccompsandbox extended to use seccomp bpf.
markus@chromium.org 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.

thanks!
will
Kees Cook - March 23, 2012, 6:14 a.m.
Hi,

On Thu, Mar 22, 2012 at 01:43:57PM -0500, Will Drewry wrote:
> On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner <tim.gardner@canonical.com> 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. :)
> >
> > So I guess it got uploaded. How about a quick description of how to
> > utilize the seccomp filter?
> > [...]
> > 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.

I've put together a little tutorial (with working code samples) on using
basic syscall filtering via seccomp filter here:

http://outflux.net/teach-seccomp/

-Kees
Brad Figg - March 23, 2012, 1:04 p.m.
On 03/22/2012 11:14 PM, Kees Cook wrote:
> Hi,
> 
> On Thu, Mar 22, 2012 at 01:43:57PM -0500, Will Drewry wrote:
>> On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner <tim.gardner@canonical.com> 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. :)
>>>
>>> So I guess it got uploaded. How about a quick description of how to
>>> utilize the seccomp filter?
>>> [...]
>>> 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.
> 
> I've put together a little tutorial (with working code samples) on using
> basic syscall filtering via seccomp filter here:
> 
> http://outflux.net/teach-seccomp/
> 
> -Kees
> 

Kees,

You are familiar with our QRT (having implemented some of it). Do any of those
tests test the seccomp filter code to see if it's functioning properly? Any
thoughts on expanding those tests to test this area more thuroughly?

Brad
Tim Gardner - March 27, 2012, 2:21 a.m.
On 03/23/2012 12:14 AM, Kees Cook wrote:
> Hi,
>
> On Thu, Mar 22, 2012 at 01:43:57PM -0500, Will Drewry wrote:
>> On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner<tim.gardner@canonical.com>  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. :)
>>>
>>> So I guess it got uploaded. How about a quick description of how to
>>> utilize the seccomp filter?
>>> [...]
>>> 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.
>
> I've put together a little tutorial (with working code samples) on using
> basic syscall filtering via seccomp filter here:
>
> http://outflux.net/teach-seccomp/
>
> -Kees
>

Kees - I've read through your tutorial. Thanks by the way for that. With 
regard to determining seccomp BPF functionality, do you think its 
sufficient to just test for one or two syscalls ? That will at least 
indicate that the seccomp subsystem is alive and functional. We could 
almost just use your example program for that.

Is there benefit to performing an exhaustive syscall filter test, or are 
all syscalls treated the same ?

rtg

P.S. I know I should just go look at the code, but I'm feeling kinda 
lazy tonight.
Will Drewry - March 27, 2012, 10:02 p.m.
On Mon, Mar 26, 2012 at 9:21 PM, Tim Gardner <rtg.canonical@gmail.com> wrote:
> On 03/23/2012 12:14 AM, Kees Cook wrote:
>>
>> Hi,
>>
>> On Thu, Mar 22, 2012 at 01:43:57PM -0500, Will Drewry wrote:
>>>
>>> On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner<tim.gardner@canonical.com>
>>>  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. :)
>>>>
>>>>
>>>> So I guess it got uploaded. How about a quick description of how to
>>>> utilize the seccomp filter?
>>>> [...]
>>>> 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.
>>
>>
>> I've put together a little tutorial (with working code samples) on using
>> basic syscall filtering via seccomp filter here:
>>
>> http://outflux.net/teach-seccomp/
>>
>> -Kees
>>
>
> Kees - I've read through your tutorial. Thanks by the way for that. With
> regard to determining seccomp BPF functionality, do you think its sufficient
> to just test for one or two syscalls ? That will at least indicate that the
> seccomp subsystem is alive and functional. We could almost just use your
> example program for that.

In general, I think that's enough.  If you want, I finally finished
porting my organically developed tests into something a "little" bit
prettier and arch agnostic which might be useful:
  https://github.com/redpig/seccomp/tree/master/tests

I believe all the tests will pass for the patch series merged, except
for one, where I tightened the mask on the return values (in a
to-be-posted v17).  No userspace code ABI changes specifically, just
ensuring a hard cap on the highest BPF return value, so nothing scary
:)

> Is there benefit to performing an exhaustive syscall filter test, or are all
> syscalls treated the same ?

Yup - the BPF is basically just a userspace API for syscall-time use
of syscall_get_number and syscall_get_arguments, and syscall_get_arch.
 So once you've grabbed one syscall number, you could've grabbed any
of them :)


The tests above don't explore all the argument edge cases,
architecture values, etc, but it covers a large amount of the ground
and fills in gaps where the kernel/samples/seccomp and Kees's tutorial
don't touch explicitly.

cheers!
will