Re: A basic question about the security_* hooks

[Casey Schaufler <casey@schaufler-ca.com>]

Kyle Moffett wrote:
> On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> 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 http://cr.yp.to/unix/disablenetwork.html 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 sandboxing.org.)
>>
>> 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,
> etc.
>
> 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.
>   

I would be very surprised if the policy you've described actually
covered all the bases. I would also be surprised if a functional
policy that meets the needs described was considerably smaller than
Lake Michigan. It's really easy to toss off the basics of what needs
to be done, it's quite another to get the whole thing right.

> The default SELinux policies are rather fantastically complicated,
>   

Everyone, I didn't say that. He did.

> mainly because they have a goal of locking down an entire GUI-enabled
> system.  

Err, even with unconstrained_t all over the place it's over a million
lines. You can't blame the GUI environment for that.

> If all you need is something much simpler, the policy
> language is very flexible and easy to customize.
>   

I'm willing to bet all the beers you can drink in a sitting that
the policy would be bigger than the proposed LSM. You can count that
in either bytes or lines.

> 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).
>
> Cheers,
> Kyle Moffett
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>