[lkml]   [2009]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A basic question about the security_* hooks
    On Sat, Dec 26, 2009 at 14:50, Michael Stone <> wrote:
    >> I ask bc the API is in the prctl code, so the LSM
    >> is conceptually always there, which is different from other LSMs.
    > The goal is to provide a stupidly simple unprivileged per-process network
    > isolation primitive which is broadly available "without jumping through
    > hoops".
    > (See for a nice writeup.)
    > I need a primitive like this to further my work on the OLPC Bitfrost
    > security
    > architecture and to further my more general work on advancing the state of
    > sandboxing technology. (See
    > I'm willing to entertain pretty much any implementation or interface request
    > which meets that goal and which implements the desired semantics.

    If you aren't using SELinux at this time (and therefore have no
    existing policy), then it's actually pretty straightforward
    (relatively speaking) to set up for your particular goals. On top of
    that, once you actually get the system set up, it's very easy to
    extend your sandbox security model to additional processes, actions,

    In this example, you would set up a very minimal stripped-down SELinux
    policy in which you only define 3 types (file_t, regular_t and
    nonetwork_t). Any process would be allowed to "dyntransition" from
    regular_t to nonetwork_t, but not the reverse. regular_t would be
    allowed to do anything. nonetwork_t would be allowed to do anything
    that (A) does not involve the network *and* (B) does not compromise a
    regular_t process. file_t would only be used for on-disk files.

    If you want to have some program binaries *automatically* run in
    nonetwork_t, you would add 1 extra type: nonetwork_exec_t. You would
    include a rule "type_transition regular_t nonetwork_exec_t:process
    nonetwork_t;" in your policy, and then allow anyone to relabel files
    between the labels "file_t" and "nonetwork_exec_t". Any program file
    labelled "nonetwork_exec_t" would automatically execute as
    "nonetwork_t" and therefore be properly sandboxed.

    The default SELinux policies are rather fantastically complicated,
    mainly because they have a goal of locking down an entire GUI-enabled
    system. If all you need is something much simpler, the policy
    language is very flexible and easy to customize.

    The best part is... when you discover you need to control additional
    actions, you can do so at runtime with zero risk of crashing the
    kernel (although you can always lock yourself into a box and force a
    reboot with bad security policy).

    Kyle Moffett

     \ /
      Last update: 2009-12-28 16:27    [W:0.024 / U:0.992 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site