[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1304699437.10692.78.camel@localhost.localdomain>
Date: Fri, 06 May 2011 12:30:33 -0400
From: Eric Paris <eparis@...hat.com>
To: Will Drewry <wad@...omium.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
kees.cook@...onical.com, agl@...omium.org, jmorris@...ei.org,
Randy Dunlap <rdunlap@...otime.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Tom Zanussi <tzanussi@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 5/7] seccomp_filter: Document what seccomp_filter is and
how it works.
On Thu, 2011-05-05 at 02:21 -0700, Will Drewry wrote:
> On Wed, May 4, 2011 at 11:46 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> In particular, if the userspace code wants to stage some filters and
> apply them all at once, when ready, I'm not sure that it makes sense
> to me to put that complexity in the kernel itself. For instance,
> Eric's second sample showed a call that took an array of ints and
> coalesced them into "fd == %d || ...". That simple example shows that
> we could easily get by with a pretty minimal kernel-supported
> interface as long as the richer behavior could live userspace side --
> even if just in a simple helper library. It'd be pretty easy to
> implement a userspace library that exposed add_filter(syscall_nr,
> filter) and apply_filters() such that it could manage building the
> final filter string for a given syscall and pushing it to prctl on
> apply.
Had a few minutes this morning so I started writing something that looks
sorta like a userspace library. It dosn't have unset yet but I don't
think it'll be that hard for me to implement. You can build some pretty
complex filters easily. Not sure when I'll get to work on it more, but
it at least shows the idea of doing the complex work in a library and
keeping a simple kernel interface.... Any thoughts?
-Eric
View attachment "libseccomp.c" of type "text/x-csrc" (6604 bytes)
View attachment "libseccomp.h" of type "text/x-chdr" (821 bytes)
View attachment "Makefile" of type "text/x-makefile" (281 bytes)
View attachment "test.c" of type "text/x-csrc" (830 bytes)
Powered by blists - more mailing lists