[cap-talk] Why protected capabilities matter
david.hopwood at industrial-designers.co.uk
Tue Jul 17 12:30:27 EDT 2007
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>
More information about the cap-talk