[cap-talk] Rob Meijer: Communicating conspirators...
Jed at Webstart
donnelley1 at webstart.com
Mon Jul 17 19:24:15 EDT 2006
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 ;-)
>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.
>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
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.
More information about the cap-talk