lkml.org 
[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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


    \
     
     \ /
      Last update: 2011-05-26 20:37    [W:4.198 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site