| Message ID | 20120321191804.GR4432@outflux.net |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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.
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
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