Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 26 May 2011 11:33:52 -0700 | Subject | Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering |
| |
On Thu, May 26, 2011 at 10:38 AM, Will Drewry <wad@chromium.org> wrote: >> >> One option is to just not ever allow execve() from inside a restricted >> environment. > > That'd certainly be fine with me.
So if it ends up being purely a "internal to the process" thing, then I'm much happier about it - it not only limits the scope of things sufficiently that I don't worry too much about security issues, but it makes it very clear that it's about a process going into "lock-down" mode on its own.
It also gets rid of all configuration - one of the things that makes most security frameworks (look at selinux, but also just ACL's etc) such a crazy rats nest is the whole "set up for other processes". If it's designed very much to be about just the "self" process (after initialization etc), then I think that avoids pretty much all the serious issues.
A lot of server processes could probably use it as a way to say "Hey, I guarantee that I will only open new files read-only, and will only write to the socket that was already opened for me by the accept", and explicitly limit their worker threads that way.
If that is really sufficient for some chrome sandboxing, then hey, that's all fine.
Sometimes limiting yourself (rather than looking for some bigger "generic" solution) is the right answer.
Linus
| |