Messages in this thread | | | Subject | Re: Using ftrace/perf as a basis for generic seccomp | From | Peter Zijlstra <> | Date | Mon, 07 Feb 2011 13:26:09 +0100 |
| |
On Sat, 2011-02-05 at 12:51 +0100, Stefan Fritsch wrote:
> A really major use case is socketcall(2). All socket related syscalls > (accept, bind, connect, receivemsg, ...) are implemented as socketcall > with an appropriate argument. There will be many cases where you want a > sandboxed process to be able to do recvmsg(2) to receive new file > descriptors over an already open unix-domain socket from a broker process. > But you may want to disallow other socket operations, especially listen, > accept, and connect. > > Of course one could also add some special case handling for socketcall > in seccomp instead of using the full filtering.
That looks like a perfect use-case for the LSM bits, attach some state to both the fd object and the task object and if they don't match, don't allow the action.
| |