|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Will Drewry <wad-AT-chromium.org> |
|| ||Re: [PATCH 5/7] seccomp_filter: Document what seccomp_filter is and
how it works. |
|| ||Thu, 28 Apr 2011 09:06:36 +0200|
|| ||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>|
|| ||Article, Thread
* 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:
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
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
to post comments)