|From:||Ingo Molnar <mingo-AT-elte.hu>|
|To:||Will Drewry <wad-AT-chromium.org>|
|Subject:||Re: [PATCH 5/7] seccomp_filter: Document what seccomp_filter is and how it works.|
|Date:||Thu, 28 Apr 2011 09:06:36 +0200|
|Cc:||linux-kernel-AT-vger.kernel.org, kees.cook-AT-canonical.com, eparis-AT-redhat.com, agl-AT-chromium.org, jmorris-AT-namei.org, rostedt-AT-goodmis.org, Randy Dunlap <rdunlap-AT-xenotime.net>, Linus Torvalds <torvalds-AT-linux-foundation.org>, Andrew Morton <akpm-AT-linux-foundation.org>, Tom Zanussi <tzanussi-AT-gmail.com>, =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec-AT-gmail.com>, Arnaldo Carvalho de Melo <acme-AT-redhat.com>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Thomas Gleixner <tglx-AT-linutronix.de>|
* Will Drewry <email@example.com> wrote: > +A collection of filters may be supplied via prctl, and the current set of > +filters is exposed in /proc/<pid>/seccomp_filter. > + > +For instance, > + const char filters = > + "sys_read: (fd == 1) || (fd == 2)\n" > + "sys_write: (fd == 0)\n" > + "sys_exit: 1\n" > + "sys_exit_group: 1\n" > + "on_next_syscall: 1"; > + prctl(PR_SET_SECCOMP, 2, filters); > + > +This will setup system call filters for read, write, and exit where reading can > +be done only from fds 1 and 2 and writing to fd 0. The "on_next_syscall" directive tells > +seccomp to not enforce the ruleset until after the next system call is run. This allows > +for launchers to apply system call filters to a binary before executing it. > + > +Once enabled, the access may only be reduced. For example, a set of filters may be: > + > + sys_read: 1 > + sys_write: 1 > + sys_mmap: 1 > + sys_prctl: 1 > + > +Then it may call the following to drop mmap access: > + prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0"); Ok, color me thoroughly impressed - AFAICS you implemented my suggestions in: http://lwn.net/Articles/332974/ and you made it work in practice! We could split out the ftrace filter engine some more and make it more independent of ftrace. It's basically an in-kernel interpreter able to run off tracepoints. I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic filters conceptually? I think we should really think hard about the actual ABI as this could easily spread to more applications than Chrome/Chromium. Btw., i also think that such an approach is actually the sane(r) design to implement security modules: using such filters is far more flexible than the typical LSM approach of privileged user-space uploading various nasty objects into kernel space and implementing silly (and limited and intrusive) hooks there, like SElinux and the other security modules do. This approach also has the ability to become recursive (gets inherited by child tasks, which could add their own filters) and unprivileged - unlike LSMs. I like this *a lot* more than any security sandboxing approach i've seen before. Thanks, Ingo
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds