[cap-talk] Communicating conspirators

[David Hopwood]

Eric Jacobs wrote:
[...]
> "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?)..."

Some capability systems have included such a mechanism, for example
the ENVRTS bit in Hydra [*].

I think that this kind of "do not delegate" mechanism is now generally
understood to be a mistake -- it complicates the system, impedes
legitimate use of delegation, and does not improve security. I hope
that any pressure to include such a thing in new cap system designs
can be resisted.

> 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 am not fond of the idea that because (1) we do not know how to
> abstract something, or (2) we do not currently have the technology to
> implement those abstractions, that it is not possible that someone
> really wants it.

I don't think the argument was that people don't want this ability.
The argument was that neither we nor anyone else know how to give it
to them.

Existing access control approaches clearly don't solve CC. The difficulty
that the cap security community seems to have is that describing capabilities
to people tends to make this problem more obvious to them, which may then
associate the problem in their minds with capabilities. I don't know
how to fix that, but it's not a technical problem with capability systems.


[*] See section 3.3 of
<http://www-static.cc.gatech.edu/classes/AY2004/cs6210_spring/papers/hydra_p141-cohen.pdf>

Even this paper was ambivalent about any benefit of limiting delegation:

# Let us briefly pause here and determine whether there really is a
# problem. For if User-1 trusts User-2 enough to let her use the Data
# object, she may as well trust that User-2 not share it with other
# users. There are a number of answers. Like the use of MDFYRTS in the
# Modification Problem, ENVRTS is simply an additional small safeguard
# against error that Hydra can provide. [...]

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>