[cap-talk] Capabilities vs. Classifications - MLS systems?

[Rob J Meijer]

> Jed wrote:
>
>>             Attempts to
>> make the enforcement of such principles "mandatory" (by that I mean
>> not allowing a
>> subject with a permission to grant effective access to that
>> permission to another
>> process with which it can communicate) in a system with inter process
>> communication I believe is impossible, but misguided efforts
>> in that direction
>> make real systems effectively unusable.
>>
> I agree, but there's another aspect to the problem, voluntary oblivious
> compliance (VOC).  Say that Alice asks Bob for a file that he can read.
> If Bob doesn't care about the rules, or he wants to break them, he'll
> get the contents of the file to Alice by some means.  No mandatory
> access control, except one that prevents him from sending a message to
> Alice, can prevent it.
>
> On the other hand, Bob may want to obey the rules, but he may not know
> them.  Real security systems are far more complex than just a single set
> of levels.  Even matrix security, with levels and compartments, doesn't
> capture all the policies people would like to enforce.  Further, the
> rules are constantly changing.  A system that supports VOC allows Bob to
> send Alice a handle to the file that Alice can only use if the policy
> allows her access.  We implemented such a mechanism in Client Utility
> (e-speak Beta), and MarkM has figured out how to do something similar in
> E.  I call this control "mandatory" if Alice's use of the handle is
> prevented by something other than the file server.  That's different
> from Jed's definition, but I believe mine has value.

I agree that the use of a single set of levels may not be sufficiently
generic. I feel that the scenario you draw here points out the actual
problem very clearly for what I sugested that a MLS (or MLS like) patern
for IPC would be valueable for.

What I believe that a generic design patern should provide
a solution for is:

1) Use by Bob of its capability to read the file should in some way
   implicitly revoke Bob his capability to send messages to Allice.
2) Bob should, if he find outs his state prohibits him from sending
   messages to Allice be able to drop all of his current state and
   restore the state he possesed prior to reading the file.

The use of ss-property and *-property enforcement as mandatory extention
to the IPC may indeed not be the best way to arive at these two goals,
but I do strongly believe a well documented viable alternative design
patern that can be used in this scenario would be an essential one.
Confinement modeling would implicitly enforce such a problem for a limited
subset. I have kind of a probably kind of fundationless preference for
implicit enforcement by trusted IPC and storage subsystems, but I think
an explicitly enforcing patern would probably indeed be more in sync with
capability modeling and could possibly thus also be allowed to be more
generic than that created by single set of levels.


Rob