[cap-talk] Communicating conspirators (Re: Second ABAC Google talk is now up)

[Rob]

>
> This was the only part of the presentation that I felt pretty
> dissatisfied with, and perhaps it has more to do with the treatment of
> the topic in the capability community in general than anything else, but
> I feel the arguments that were given were not convincing and did not
> resolve the question that was originally asked.
>
> The original comment at 29:15 - (something like this, the audio is
> fuzzy)
>
> "So, I just want to say here as well: I don't want Bob to have a
> reference to Carol except in the scope of the Foo operation. I
> don't want Bob to be able to save that (access?)..."
>
> 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 ;-)

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. 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 can hold
on to (t.i. blocking) communication for Bob on incomming communication
channels where the lables mismatch the current tainting of Bob.
As soon as Bon indicates to its proxy that is 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.

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.

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