[cap-talk] membrane challenge - network Bob, SN?

[David Hopwood]

Jed at Webstart wrote:
> At 05:52 PM 11/18/2004, David Hopwood wrote:
>> Jed Donnelley wrote:
>>
>>> My assumption for the attack is that the SN doesn't have any rights
>>> to begin with.  The SN is just a server that can allow one to 
>>> effectively
>>> "park" a capability (descriptor based capability) and get back a token
>>> (the Swiss Number) to retrieve it at a later time.
>>> I think it reasonable that both Alice and Bob might have access to
>>> such a service, represented by the SN capability.  Note that the
>>> SN capability by itself doesn't convey any rights.  One must submit
>>> a Swiss Number to the SN server to retrieve a capability previously
>>> parked there.
>>
>> Of course the SN capability conveys rights.
> 
> In the same sense that an sshd server conveys rights.

Yes, approximately. But that is a very significant sense, which is
important to model correctly.

Consider the following simpler example. Capabilities A and B provide
no authority other than the following: if A and B are combined, they
give access to C, which conveys some direct authority.

Thinking of A and B as not conveying any rights leads to nonsensical
conclusions. For instance: "A conveys no rights. B conveys no rights.
Therefore holding A and B conveys no rights." The flaw in this argument
is obvious when A and B are explicitly described as above, but not if
you think of, say, A as being the "real" capability and B as "just"
an enabling capability that is safe for anyone to hold.

The SN server example is not as symmetrical as this example, but it
is similarly an instance of synergy: both knowledge of the Swiss Number
'SNFoo' and access to the server are needed to look up 'Foo', therefore
both convey rights.

> If you
> don't have the "capability" (i.e. haven't been granted authorization)
> it conveys almost no rights (to probe for holes perhaps).

Bad model. The sshd server conveys the right to convert knowledge of
the private key to the ability to establish a session secured by that
key. The SN server conveys the right to convert some set of Swiss
Numbers to capabilities (and to change/add/remove the mapping of a
given Swiss number).

[...]
> Does this seem to be getting a bit convoluted?  I think so.
> I'm hoping to use that complexity in arguing for a simpler
> capabilities as data model (protocol) that can pick up the
> confinement value of partitioned capability systems in
> a TCB implementation supporting the protocol.
> 
> We can all dream.

I think this is not actually a simplification because, on any given
machine, capabilities and data must be distinguished by type anyway.
At least, they must be distinguished by application languages, even
if the underlying cap system is a non-language-based password system.
The complexity of having to proxy between a partitioned system on
each machine and a networked capability protocol (hence using a data,
but not necessarily password, representation of capabilities) is
unavoidable complexity.

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