Messages in this thread | | | Subject | Re: Using ftrace/perf as a basis for generic seccomp | From | Eric Paris <> | Date | Wed, 02 Feb 2011 11:45:22 -0500 |
| |
On Wed, 2011-02-02 at 13:26 +0100, Ingo Molnar wrote: > * Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote: > > > Hi Eric, > > > > (2011/02/01 23:58), Eric Paris wrote: > > > On Wed, Jan 12, 2011 at 4:28 PM, Eric Paris <eparis@redhat.com> wrote: > > >> Some time ago Adam posted a patch to allow for a generic seccomp > > >> implementation (unlike the current seccomp where your choice is all > > >> syscalls or only read, write, sigreturn, and exit) which got little > > >> traction and it was suggested he instead do the same thing somehow using > > >> the tracing code: > > >> http://thread.gmane.org/gmane.linux.kernel/833556 > > > > Hm, interesting idea :) > > But why would you like to use tracing code? just for hooking? > > What I suggested before was to reuse the scripting engine and the tracepoints. > > I.e. the "seccomp restrictions" can be implemented via a filter expression - and the > scripting engine could be generalized so that such 'sandboxing' code can make use of > it. > > For example, if you want to restrict a process to only allow open() syscalls to fd 4 > (a very restrictive sandbox), it could be done via this filter expression: > > 'fd == 4' > > etc. Note that obviously the scripting engine needs to be abstracted out somewhat - > but this is the basic idea, to reuse the callbacks and reuse the scripting engine > for runtime filtering of syscall parameters.
Any pointers on what is involved in this abstraction? I can work out the details, but I don't know the big picture well enough to even start to move forwards.....
-Eric
| |