[cap-talk] Communicating conspirators

[Toby Murray]

Mark S. Miller wrote:

>David Hopwood wrote:
>  
>
>>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.
>>    
>>
>
>Sadly, <http://eprint.iacr.org/2005/169.pdf>
>"Enforcing Confinement in Distributed Storage and a Cryptographic
>Model for Access Control"
>by Shai Halevi, Paul A. Karger, Dalit Naor
>
>Paul Karger is a famous security and capabilities guy who knows about EROS. I 
>was surprised to see this.
>
>  
>
An interesting thing about this paper is that it seems to argue that 
EROS achieves confinement by limiting delegation. I had thought EROS 
achieved confinement by limiting the capabilties that a confined process 
holds, thereby limiting the other objects to whom it can delegate.

It also seems to argue that Lampson's confinement and the *-property are 
the same. I wasn't aware of that before, is this generally accepted? I 
can see how Lampson's confinement allows one to enforce the *-property 
but I wasn't aware they were considered equivalent. Can one have the 
*-property without Lampson confinement, for example? Or are both terms 
used generally to refer to the ability to construct one-way data 
channels between objects?

I personally see Boebert's claim that the *-property cannot be enforced 
in a "pure cap system" the same as the HRU result that safety is 
generally undecidable. That is, it's true if you have a weak enough 
system, (such as a pure caps-as-data system), but doesn't apply to all 
real systems of interest (such as EROS or E) in which data and 
capabilities can be distinguished. It's interesting that they cite DVH 
as an example in which the *-property cannot be enforced. This is in 
stark contrast with CapMyths which argues that DVH is equivalent to the 
object-capability model, not the weak model used by Boebert etc. in 
which capabilities and data are not distinguished.

It's interesting to revisit the arguments in CapMyths in light of Karger 
et. al's assertion that EROS achieves "confinement" (the *-property) by 
limiting delegation. Briefly, as to my understanding, in CapMyths, its 
shown that we can of course enforce the *-property using nothing but 
pure capabilities so long as there is a distinction between capabilities 
and data, such that we can build a one-way communication channel that 
only allows data to flow and not capabilities. One could argue that in 
this setting we have "restricted delegation" because one cannot pass 
caps over this channel so one cannot delegate. Perhaps it is in this 
vein that Karger et. al. are thinking when they say that EROS achieves 
the *-property by limiting delegation.

Just some thoughts.

>  
>
>>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.
>>    
>>
>
>Only when people understand that it's impossible by any means will they stop 
>reacting badly when they notice that it's obviously impossible in objcap 
>systems. That's why I spent time trying to explain this in my talk.
>
>  
>


-- 
Toby Murray
Advanced Computer Capabilities Group
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.