Re: Mandatory Access Control

[robert () dyadsecurity com]

Peter Busser(busser () m-privacy de)@Fri, Dec 03, 2004 at 02:28:57PM +0100:
> That's an interesting, but a bit too optimistic article which is wrong
> in several places.

As stated in the opening paragraph, it is introduction and not intended
to be a full paper on the subject.  I agree that it is optimistic, and
I'll say a bit incomplete for clarity's sake of a reader who has no
experience with the concept.

> 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. 

Correct.

> 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.

Agreed.  I had intended most of this part of the conversation to be in
the next article.

> 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.

I completely agree with this.  However without the Mandatory part, any
policy becomes less meaningful because it is not enforced. For example,
Discretionary RBAC does not provide the security assurance we're looking
for.

> This means that real ``least privilege'' MAC policies are impossible
> to create. And that is why you always need DAC besides MAC.

I humbly disagree with this, but I will say that it perhaps depends upon
what you are trying to do.  If an organization's security policy is
clear, then it may be a good idea to supply technology that has a chance
of delivering on the requirements in the security policy.  If it's not a
requirement for the organization, then don't spend the time.  If it is a
requirement, it's not "too hard" to implement =).

> 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.

I also value choice.  I'll research those other projects more to make
sure they fit the capabilities that we want to highlight.  It's been a
little while, but last time we looked at grsec, it didn't have the same
fine grained capabilities that SE Linux had. Although we do value his
work on PaX.

Robert

-- 
Robert E. Lee
CTO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - robert () dyadsecurity com
M - (949) 394-2033
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave