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

[Rob]

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

With clasic MLS a process/object has something called a (static) clearance
level. With capabilities however, it is not the process or object that has
clearance but the capability. By using an MLS style clearance like lable
for each capability, making the lable an intrincic part of the capability,
a proxy can be created around each objects in order to help the object
to become able to handle capabilities with different values for this label.

When you define this proxy to be both bag and membrane, the proxy can
keep track of the 'tainting' of the object. If the object fetches a
capability from the proxy (bag) or receives one in a method call, the
object will get "tainted" to the highest value of a capability it holds.
If after receiving a high labled capability the object tries to use a low
labled capability, the proxy would interpret this as an aparent flaw in
the object, and the object could be killed and be restored in its state
to a previous level. Its a bit more complicated than this, but this
is about the rough picture.

This means the MLS properties get effectively deminished to:

'An object may not combine capabilities with different labels'

The proxy patern for this is a bit complicated, but the resulting
property is quite usefull for solving the described problem.



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