[cap-talk] Mandatory Access Control: unidirectional state changes

[Jed Donnelley]

At 01:54 AM 1/5/2007, Rob Meijer wrote:
>On Thu, January 4, 2007 09:32, Ka-Ping Yee wrote:
> > After looking around some more it is starting to appear to me
> > that the confusion about the terms MAC and DAC stems from the
> > fact that each term is used in two distinct ways:
> >
> >     - to refer to a quality of access control models
> >
> >     - to refer to a specific method (the most common method)
> >         of implementing access control that bears that quality
> >
> > In the case of DAC, the quality is "local or user-level control
> > over access policy" and the implementation is "objects have owners
> > that can edit their ACLs".
> >
> > In the case of MAC, the quality is "global or system-level control
> > over access policy" and the implementation is "compare the subject
> > clearance level to object's sensitivity label".
>
>I think MAC vs DAC is not an issue of local vs global but rather an issue
>of unidirectional state changes vs bidirectional state changes.
>As in MLS according to the MAC at a user level of controll a data object
>can have its state changed to a higher clasification level but can not
>reverse this descission. I feel that in MLS MAC only provides the
>mechanisms of unidirectional state changes at a global level, rather than
>moving controll to a global level. I feel that any access controll mechanism
>that provides the posibility to do unidirectional state changes provides MAC,
>while any access controll mechanism that provides the ability to do 
>bidirectional
>state changes would thus provide DAC.

To me confusion on this topic (MAC vs. DAC) seems to be reaching an epic
level.  In the above description we seem to have an instance of discretionary
management (the raising of a security level for an object) of a 'mandatory'
control.  I'll note in this context that such an act can enable access that
was previously prohibited.  For example in the case of MLS, a write to an
object with a lower level may be prohibited at one point (due to the 
* property)
and then, after a discretionary change as above, be permitted because the
level of the object is now >= than the clearance of the subject doing
the writing.

I truly despair that we'll be able to provide any meaning to the distinction
between MAC and DAC from the perspective of the "access matrix".

I  think of MAC controls as being communication restrictions (e.g. for
the MLS case think of the simple security and * properties as restrictions
on who can communicate to who, only allow send to up and read from down)
with derived "access matrix" restrictions - necessitated to make the
communication restrictions transitive.  In fact, if you imagine the servers
of objects participating in the communication restrictions with their own
clearance levels (or compartment labels), then the access matrix sorts of
restrictions become automatic.  Unfortunately it also means that something
like a multi-level file server in an MLS system either can't receive 
requests or
can't send replies to requests (depending on which direction the request
crosses a level boundary), but if you focus on the data flow (vs. control flow)
in file operations then the communication restrictions do "the right thing" for
MLS.

I don't think this helps with the definition problems and resolving historical
usage, Bell and LaPadula, etc., but I throw it out in case it might 
fit with anybody
else's thinking.

Regarding:

At 12:20 PM 1/5/2007, Rob Meijer wrote:
>On Fri, January 5, 2007 16:32, David Wagner wrote:
> > Rob writes:
> >>I think MAC vs DAC is not an issue of local vs global but rather an issue
> >>of unidirectional state changes vs bidirectional state changes.
> >>As in MLS according to the MAC at a user level of controll a data object
> >>can have its state changed to a higher clasification level but can not
> >>reverse this descission.
> >
> > MLS is not the same as MAC.
>
>Agreed.
>
> > Not all MAC systems need to take the form
> > you are describing.
>
>The only MAC systems I currently know of that is not MLS related does take
>this form, and is concerned with the non revertableness of making data
>immutable. That is, it is not MLS but still does nothing but provide a
>mechanism for unidirectional state changes.
>Could you give an example of an implementation or design that does not
>provide its MAC as unidirectional state change mechanism?

Alan Karp previously mentioned "compartments."  I'm not familiar enough
with any implementation of compartments to know what sorts of
communication are permitted between compartments (presumably
there must be some or we wouldn't talk about a 'compartments'
mechanism for a single system).  Perhaps Alan can further explain
or provide pointers.  If 'compartments' really is an alternative form
of MAC, then perhaps I can see whether it fits with my notion that
MAC at heart derives from communication restrictions.

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