[cap-talk] Rob Meijer: Communicating conspirators...

[Jed at Webstart]

At 02:29 AM 7/17/2006, Rob wrote:
> > ...We are told that this is an example of Communicating Conspirators
> > and that will be addressed later in the presentation. This main
> > points made are:
> >
> >    - that CC cannot be solved with permissions;
> >    - that CC cannot be solved with capabilities;
> >    - that the capability security model cannot solve CC because
> >      in its formal system, CC is not distinguishable from other
> >      situations that are not security problems
> >    - and therefore, CC is an impossible problem to solve (!)
>
>I believe this is a problem where MLS may offer a solution.
>You need to look at auto-respawning meganisms combined with
>something like the 'no read up' 'no write down' principles from MLS.
>I explicitly write "like" as not to spark of an other 'MLS is evill'
>rant by some on this list ;-)

Sorry.  No chance (though of course I'm not "this list").  The MLS 
principles (no write down and no read up) simply can't work in any 
multilevel interprocess communication system.

Consider the simple case of a client/server request/reply model.  A 
message (data) goes from the client to the server, a reply (data) 
goes from the server to the client.  If the server  runs at a 
different level than the client you have write down and read up - 
regardless of which is higher.   It simply can't work.  I'm quite 
sympathetic to the basic values that the MLS model (Bell LaPadula) 
tries to bring.  I spent some 15 years at LLNL trying to reconcile 
that model with an interprocess communication system.  We had limited 
success by allowing explicit overrides - though of course that makes 
the model "discretionary" and violates the very core of the needs of 
those who believe most in "mandatory" MLS.  Eventually (after I left) 
people at LLNL completely gave up on MLS in their networked systems 
(systems now all run at a single level).  If the MLS model can't work 
at a place like LLNL where the need is greatest, I argue it simply 
can't work in a network anywhere.

If you have a working MLS system that enforces the simple security 
property (no read up) and the * property (no write down) in a network 
communication system (really the same when you think about it from a 
communication viewpoint), I'd be very interested to hear how it deals 
with simple client/server communication.

Regardless, even given the above, one could conceive of something 
along the lines of MLS principles that could be applicable to the 
communicating conspirators problem, so I'll soldier on.

>I've tried to discuss this a number of times on this list before and a lot
>of people on the list seem to find it rather impractical and/or have a
>deeply rooted aversion against anything MLS related.
>Nevertheless I will give tit an other try. I'll try this time to discuss it
>without resorting to MLS teminology, maybe that will help a bit ;-)

Ditto above.

>What you need to do is that you need to define a proxy that holds each of
>Bobs communication channels, acts as a bag to Bobs capabilities and is
>able to respawn the Bob object.

I believe this assumption (the ability to "respawn" Bob) takes you 
out of the realm of solving the communicating conspirators 
problem.  In the general case (somebody correct me if I'm wrong) the 
conspirators are managed under distinct domains somewhere on a 
network.  Any data that Bob gets (e.g. with the authorities provided 
by Alice) are Bob's for the duration.  Permissions (e.g. in the form 
of capabilities) can be revoked at any time, but of course for both 
Bob and any delegated to Mallet (whether by proxy or no).

>All data and capabilities sent to Bob are
>by its 'labels' used to 'taint' Bob. The proxy can than use this tainting
>of Bob to disalow the further usage of outgoing communication to
>communication channels with mismatching labels. Further the Proxy

I'm a bit unclear on what "the Proxy" is in the scheme you are 
describing.  The only proxy that makes sense to me is Bob or some 
active entity acting on Bob's (or perhaps Alice's) behalf.

>can hold
>on to (t.i. blocking) communication for Bob on incomming communication
>channels where the lables mismatch the current tainting of Bob.

I'm not sure how any labels might play a role in this scheme.

>As soon as Bon indicates to its proxy that is ready to be interrupted,

Did you mean Bob above?  Remember that Bob is a co-conspirator.  What 
would motivate Bob to indicate that it is so "ready to be interrupted"?

>the proxy can choose to kill and respawn Bob to than restore Bob's state
>only upto the tainting required by its lowest label pending blocking
>incommunication call.

Certainly killing and restoring Bob's previous state could block any 
information not already delivered to Mallet.  I don't believe that in 
any sense "solve"s the cooperating conspirators problem, but it would 
mitigate future "leak"s - IF some higher authority existed with a 
permission to so kill and restore Bob.

>This solution may be a bit complex and more than a bit cumbersome, but
>it does allow Bob to know about things when he needs them and forget about
>them in a validatable way when he no longer requires them.

Still sounding like Bob is not a co-conspirator, but is instead 
trying to cooperate.  In that case you are addressing the problem of 
the Confused Deputy rather than that of Cooperating Conspirators.

Incidentally (minor note on presentation), I think Mark meant to say, 
at 39.57, "Can Mallet break in and take it?" - rather than "Can Bob 
break in and take it." - when discussing the Perimeter Security case.

>(p.s. I hope I succeeded in keeping any offending MLS lingo out of 
>my description this time ;-) )

I don't think the lingo matters.  What matters are the fundamental 
mechanisms and concepts.

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