[cap-talk] Mandatory Access Control (was: What's "Discretionary Security")

Jed Donnelley capability at webstart.com
Wed Jan 3 12:02:18 CST 2007


At 03:10 AM 1/3/2007, Ka-Ping Yee wrote:
>On Tue, 2 Jan 2007, Jed Donnelley wrote:
> > I just thought I'd extend out a bit beyond the list to see if I 
> could find any
> > more modern sense in the terms "mandatory" and "discretionary" with
> > regard to access control.
> >
> > Regarding MAC there's this:
> >
> > http://en.wikipedia.org/wiki/Mandatory_access_control
>
>The articles on access control in Wikipedia seem pretty unclear and
>in many places inaccurate.  I ended up making a bunch of edits just
>now on "access control", "access control lists", and "discretionary
>access control".

Super!  Thanks Ping.

>I have by no means removed all the inaccuracies -- please check out
>these articles and feel free (even encouraged!) to make your own
>improvements to them.

Let me just feed a bit off what's now on the "discretionary access 
control" page:

http://en.wikipedia.org/wiki/Discretionary_access_control

Namely where it says, "A system is said to provide discretionary 
access control if the owner of an object has the ability to control 
how others can access it. This is defined in opposition to mandatory 
access control (also known as non-discretionary access control), in 
which the system enforces restrictions on how access policies can be edited."

and explain why this still doesn't make sense to me.  Sorry to be 
such a stick in the mud about this.  I do believe there's a core 
issue here that we need to clear up.

Firstly, in any access control scheme it's always "the system" (TCB 
code) that enforces access control restrictions, using data specified 
by those subjects doing the controlling.  In an MLS system, for 
example, it's those subjects that specify the labels on the subjects 
and objects that are doing the controlling.  In an object-capability 
system it's TCB code that enables invocations on capabilities with 
their potential for communicating capabilities and they access they convey.

Secondly, let's consider what the notion of being "the owner" of an 
object means in the context of discretionary vs. mandatory access 
control.  In some contexts (Unix comes to mind) "owning" an object 
means that the subject (owner) does have the ability to control 
access to the object.  So far so good.  That suggests at the meaning 
of the M. vs. D. access control distinction.  Presumably owning means 
that the subject (owner) had the ability to access the object even in 
a MAC system.  Is there any question about this?

Now consider the ability to share access by an owner in a MAC 
system.  As we know with the communicating conspirators problem, a 
subject with access to an object can share that access (by proxy if 
in no other way) with any other subject that the owner can 
communicate with bidirectionally.  This seems to suggest that any 
meaningful controls available from MAC enforcement policies must come 
from restrictions on communication between subjects - NOT on 
restrictions on access to objects per se.  It's certainly true that 
communication can happen also through shared object access, so a MAC 
system must include both notions, but there seems to be something 
about MAC access control that inevitably leads to communication 
restrictions.  It has been quite difficult for me to avoid dropping 
into MLS terminology and talking about communication diodes in this 
paragraph.  Perhaps with my wording others can sense why?  Is MAC 
really just another name for MLS?  If no, perhaps somebody could 
suggest a MAC scheme that isn't MLS?

I believe the tension described in the above paragraph is at the 
heart of why the MAC "community" (for lack of a better term, TCSEC, 
etc., etc.) is antagonistic to object-capability systems, and visa 
versa.  The MAC community feels that the basic object-capability 
model is too laissez faire when it comes to access control (if "I" as 
a subject have access to an object and I can communicate to "you" 
then I can share access with you), while the object-capability 
community feels that they're providing all the control that's 
possible in any model.

Does anybody see a possible resolution here?

--Jed  http://www.webstart.com/jed-signature.html 




More information about the cap-talk mailing list