[cap-talk] Capability MLS scheme using Horton (was: Re: Negative permissions)

[Jed Donnelley]

On 2/4/2008 11:06 AM, Jonathan S. Shapiro wrote:
> On Mon, 2008-02-04 at 09:55 -0800, Jed Donnelley wrote:
>> At 08:46 AM 2/4/2008, Karp, Alan H wrote:
>>> Jed wrote:
>>>> At this point I feel I have such a clear view of how
>>>> these mechanisms are working, it seems a shame that I
>>>> don't have an opportunity to work on architecting a
>>>> system with them - e.g. a capability based system
>>>> with some identity based controls (e.g. MLS).
> 
> MLS does not entail identity-based controls. It entails domain-based
> controls. There is nothing in the implementation of an MLS system that
> benefits significantly (even if viewed purely from an efficiency
> perspective) from identity-based controls in the core kernel.

Hmmm.  In most MLS systems that I'm aware of it is people
who have clearances and objects (usually files) that
have classifications.

It's true that executing programs inherit clearances from
the people who run them, and you can consider these to
be executing in domains that require control (lest the
information they read or write inappropriately get
back to the wrong person by violating the simple
security or star properties), but it's still people and
their clearances that I believe are the primary source
of concern and need for control.

It's simple enough that I think I can describe the
whole 'Horton' MLS scheme that I imagine (blue sky),
so let me take a crack at it - it may help to think
it through a bit more here:

With this scheme all communication (at least
ordinary "user" communication) goes through
Horton tunnels and carry labels indicating
their full delegation path.  This might seem
like a heavy cost, but this approach also
provides ample opportunities for optimization.
E.g. domain changes can be cut down by not
requiring them for trusted Horton modules -
or perhaps the Horton mechanisms in the
"TCB" could be separated from other aspects
of the TCB by language means.

This scheme is still purely object capability
at the interface level, because all requests
for access are by capability invocations, and
capabilities can be communicated through such
invocations (though as noted they pick up
Horton labels going in and coming out as
per the Horton "membrane").  However, of
course the Horton PDP is in the middle of
every invocation and enforces the MLS
properties.  This means that access rights
can change by means other than delegation
such as changes in clearances of people
or changes in classifications of information
objects.

I think at this point all the necessary
information is available, and it is 'just'
a matter of doing the right MLS thing when
requests are made of information resources.
There are many ways this could be done.  I'll
suggest one for concreteness.

Suppose the information resources accept
parameters that can tell them to either:

a.  Block writing (sense-only, "sensory")
or
b.  Block reading (write-only)

<note, this isn't a capability property, but
rather an explicit parameter in requests.
A bit odd perhaps and just one means, but
let me continue>

This parameter can come with any other
request that might result in reading or
writing.  The idea is to get Horton out
of the business of having to understand
the semantics of such information containing
resources.

At this point Horton is in a position to
enforce the MLS properties.  What it does
is for every request on an information
containing object (perhaps all?) it
knows:

1.  The classification of the object (presumably
it can ask for this), and

2.  The clearances of all the IDs on the
delegation path.


When a request comes through it considers
two possibilities:

A.  The minimum of the clearances for the
IDs in the delegation path is less than
the classification of the object.

     In this case it sends the Block
read parameter along with the request.

This enforces the simple security
property.

B.  The maximum of the clearances for the
IDs in the delegation path is greater than
the classification of the object.

      In this case it sends the Block
write parameter along with the request.

This enforces the * property.


I believe that with the above (fingers
crossed, blue sky) we get all the best
properties of both capabilities and
MLS.  We get POLA (all delegation can
be on a need to know basis and done
with capability communication), and
MLS MAC.  I also believe there is
no potential for confused deputies
(at least directly introduced by
the architecture).

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