lkml.org 
[lkml]   [2011]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Using ftrace/perf as a basis for generic seccomp
From
Date
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



\
 
 \ /
  Last update: 2011-02-02 17:49    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site