[cap-talk] Why protected capabilities matter

[David Hopwood]

Jonathan S. Shapiro wrote:
> On Mon, 2007-07-16 at 23:25 -0700, Jed Donnelley wrote:
[...]
>> [...] The goal of this example consideration is to:
>>
>> 1.  Store the data needed to effectively convey the needed
>> permissions (designation, permission, permission to communicate)
>> in the processes memory space, while at the same time:
>>
>> 2.  Protecting it from any sort of leakage (even deliberate
>> leakage through a covert channel, though of course proxying
>> though a covert channel would be possible as with capabilities
>> as descriptors) by encrypting it while it resides in the
>> processes memory space with a key known only to the TCB.
> 
> Then I would characterize this as protected, but not confinable, which
> is (I think) what I said initially.
>
>>> Yes. Reluctantly, because I'm not interested in protected capabilities
>>> per se, but rather in systems providing observable confinement.
>>
>> I believe the above scheme provides confinement, though not
>> "observable" confinement I think by your definition.  I have
>> to admit that "observable confinement" is a rather strange notion
>> to me in that it seems so limited to systems that are almost
>> fully controlled by one party and thus, to me, not very useful
>> for cross organizational communication (e.g. of permissions).
> 
> Then you misunderstand the requirements. Observable confinement does not
> require that the process have no initial outward communication. It
> requires that all initial outward communication held by the process be
> knowable. I am not aware of any data-cryptographic scheme that can, in
> principle, satisfy this.

Define a "capability index" to be the value that a domain uses to refer
to a capability.

The Managing Domains public key mechanism uses capability indices with
per-domain validity. In this case, the initial outward communication is
knowable because initially (as a domain is constructed), no capability
indices are valid for that domain. Only a kernel can generate valid
indices for one of its domains. This argument can be applied to any index
representation (cryptographic, sparse, C-list indices, etc.), provided
that *knowledge* of an index valid for one domain does not imply *access*
to any capabilities in other domains.

The unusual aspect of the Managing Domains PK protocol is that there
is a way to convert from an index valid for domain A to an index valid
for domain B, but only with the cooperation of the kernels for *both* A
and B. This appears to preserve confinability.

(Caveat: the protocol seems to be making some rather strong unstated
assumptions about the public key scheme.)

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>