[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

* Masami Hiramatsu <> wrote:

> Hi Eric,
> (2011/02/01 23:58), Eric Paris wrote:
> > On Wed, Jan 12, 2011 at 4:28 PM, Eric Paris <> 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:
> >>
> 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

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.



 \ /
  Last update: 2011-02-02 13:29    [W:0.050 / U:14.968 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site