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

[Jed at Webstart]

At 12:14 PM 1/5/2006, Rob J Meijer wrote:
>...
>
>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.

Lovely.  Try explaining that one to your users.

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

I don't believe that such a scenario will ever play out (code won't
be written or executed) in any system with a significant market
presence.

>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
>pattern that can be used in this scenario would be an essential one.

You seem to mean an alternative design where permissions can be
granted "without worry" and the 'right thing' (non access) will happen
automatically by some overarching policy.  I've done my best to argue
that any such approach will turn out to be counter productive, wasting
the time of a lot of people (you and others).

>Confinement modeling would implicitly enforce such a problem for a limited
>subset.

Please be careful when you use that term "confinement".  Perhaps we need
some other term for one or the other of:

1.  Confinement - limited to only specifically allowed channels of 
communication

(e.g. as they say in the Capability Myths paper:  <capabilities make> 
"confinement
possible, since no capability transfer can introduce a new connection 
between two
objects that were not already connected by some path." (a 
capability).  Of course then
they go on in the Capability Myths paper to discuss:

"the fundamental flaw in an unmodified capability system; two 
programs which can
communicate object references can share their capabilities without 
system mediation."

or:

2.  Confinement - restricted in the ability to share permissions even 
within the
      constraints of #1.

#1 is what capabilities provide directly.  I believe it is appropriate and
valuable and doesn't create any problems.  #2 is what I've been arguing
so long and hard against as impeding POLA communication and thereby
standing in the way of real security/integrity.  I believe not providing for #2
in fact makes systems more secure by providing for POLA communication.

It's certainly true that if "I" believe the process (subject, active 
object), Bob,
at the other end of a communication channel (capability) is trustworthy and
I need to share a permission with him, that I can still share a revokable or
otherwise filtered (reduced access, audited, etc.) capability with it to
retain as much control as possible.  However, when it comes down to
the final sharing:

1.  I am trusted with the base capability,

2.  I am trusted to communicate to Bob, and

3.  I believe trusting Bob with some capability is both needed and safe,

then I share the capability with Bob.  Anything that stands in my way
is counterproductive (e.g. forcing proxying or some other sort of awkward
work around).

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

There are certainly many enforcement patterns that one can create,
even very complex ones with compartments and such, with straight
capabilities that can be communicated.  That is, one can set up many
such mechanisms using #1 above and not (I believe) starting to work
against real security/integrity by trying to do something along the
lines of #2 above.

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