Mandatory Access Control (Was: Re: RE: This mornings Security Wire Perspectives - Ira's proof of concept code article.)

[Peter Busser <busser () m-privacy de>]

Hi!

> See http://www.dyadsecurity.com/papers/rbac.html for a more detailed
> view into my thoughts on that stuff.

That's an interesting, but a bit too optimistic article which is wrong in 
several places.

First of all, the kind of DAC we are most familiar with, the UNIX access 
control, was designed for a non-networked research environment with trusted 
users. It is rather obvious that this design assumption does not hold on the 
Internet or in corporate networks.

Second, MAC is a generic term. It means that there is a security policy which 
is enforced by the system. There are many ways to implement such a mechanism. 
Most of them are implemented according to one or another scientific model. 
The first and most well-known MAC model was the Bell-LaPadula model, which 
modeled how the military hierarchy works. The TCSEC definition describes this 
model. But it is an outdated definition, just like most of TCSEC is outdated.

BLP and RBAC are just two examples of MAC models. All have their strengths and 
weaknesses. There is for instance also the Clark-Wilson model, which provides 
integrity guarantees. Or the Privacy Model, designed by Simone 
Fischer-Huebner, which models the EU privacy laws (see also www.rsbac.org). 
And many others.

People choose models like RBAC over models like BLP, because they are more 
generic. This means that you can create a security policy which closely 
matches the properties of the BLP model, but you could also implement various 
other security policies. The cost however is complexity. If you try to do 
something like BLP in RBAC, then you have to put stuff in the policy which 
would otherwise be implemented in code. You can of course ask yourself what 
would be the most efficient way to implement what you need.

Third, people always talk about ``least privilege'' in connection with MAC. It 
is not MAC in itself which is going to provide this ``least privilege'', it 
is the policy which does that. Designing a policy is a lot of work. The finer 
grained the policy, the more work it becomes. This means that real ``least 
privilege'' MAC policies are impossible to create. And that is why you always 
need DAC besides MAC.

Fourth, it would be nice to also mention the various other Linux MAC security 
projects, such as RSBAC (www.rsbac.org), gr-security (www.grsecurity.net) and 
LIDS (dunno the URL, try freshmeat) and perhaps a few others which I forgot 
or don't know. As Rob Pike pointed out in an essay on freshmeat, the market 
has decided for the POSIX API and this basically killed OS research. The same 
thing will happen with OS security research when the market decides for 
SELinux as the only way of implementing MAC. That would be really sad IMHO.

Groetjes,
Peter.
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave