On Fri, 25 Aug 2006, Elad Efrat wrote:
> Travis H. wrote:
>
>> If you have any URLs handy, I'd like to see them.  OTOH, I can google
>> and if you don't have any handy will do so.  Thanks for the reference.
>
> Nope, none at hand, but the design of LSM, on top of which SELinux is 
> implemented, should give you a rough idea of one attack vector. Either way, 
> let's not make *that* the center of our discussion; see below:

I'm not convinced that's a firm argument: LSM, like kauth(9), relies on being 
implemented properly.  Like kauth(9), it has hooks all over the place, must 
properly interact with kernel subsystems, and so on.  There's certainly more 
to LSM, in that like the MAC Framework it supports control of a broader set of 
system behaviors, security labeling, and so on, but most of the other 
differences are gloss -- do you have lots of function pointers, or lots of 
enumerated constants.  kauth(9) was designed and implemented with full 
awareness of the MAC-related work on various platforms, and intentionally 
provides a limited subset of that behavior in ordeer to provide a narrower set 
of functionality with a fixed ABI for third party security providers.

>> It's actually not too bad if you already know m4 and understand TE/DTE. 
>> I've written policy modules for procmail/nmh.
>
> A rough assumption would be that 99% of NetBSD's userbase does not know m4 
> *and* understands TE/DTE enough to create their own policies; nor they 
> should. Part of what I'm interested in, beyond implementing yet another 
> security architecture, is making it also as easy as possible to use.

I'm not sure that the criticism you're making is entirely fair: perhaps 99% of 
the user base also doesn't program in C or speak BSD make.  SELinux's 
"configurability" is a bit like the "reprogrammability" of open source UNIX -- 
you need a compiler and serious domain knowledge to get anywhere.  As such, it 
is largely being targeted at satisfying integrity requirements associated with 
applications and software configurations.

> If we provide a framework that is complicated to understand, configure, use, 
> and debug, people will simply not use it, or use it "blind-folded". I think 
> providing strong *and* usable security is a more interesting goal than 
> supporting a security architecture that it is still unclear whether the 
> majority of our userbase will benefit from.

Are most users qualified to make fine-grained security decisions about how 
their applications operate?  Making something simple to configure doesn't make 
it easy to use.

Not that I don't agree in general with your argument, but I think sweeping 
statements about "ease of use" need to be avoided.  Security *is* complicated, 
because, at its core, it has to do with the complex interactions of complex 
systems.  You may not implement Biba as an abstract policy, but the ideas 
behind it are behind the notion of protecting a system: how do you limit the 
effects of compromise to subsets of the system, and what does compromise mean? 
Providing a simple menu of hardening options is extremely useful, but somehow 
those hardening options do have to be crafted with all the domain knowledge of 
the implementation of the system, since that knowledge is key to protection of 
the system.  kauth(9) doesn't remove that requirement -- it's a vehicle for 
people with domain knowledge to provide tools to people without domain 
knowledge.  Theframework is less complex, and less capable, but the underlying 
idea is the same.

Robert N M Watson
Computer Laboratory
University of Cambridge