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

Jed at Webstart donnelley1 at webstart.com
Fri Nov 19 17:29:41 EST 2004

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

>The argument you're making
>applies only to the extent that Swiss Numbers are a reasonable
>representation of capabilities. The SN server implements part of a
>password capability system, in such a way that any capabilities that
>Alice (or whoever) entrusts to the SN server will be subject to the
>limitations of password capability systems.

Right.  So, in a password capability system (e.g. Amoeba, NLTSS,
...) when you say the servers convey rights, they do so when
presented with valid capabilities to the rights.  Ditto SN.

OK - now consider the possibility that Bob is somewhere else
on the network.  In fact one could go so far as to place Bob
on a system where the form of the capabilities are data but
in a form where the message passing system requires valid
capabilities for communication (as you might have noticed I'm
beginning to push).  In other words, the form that the SN server
returns must be in a form (or translatable into a form) that the
TCB on Bob's system recognizes it as a right to communicate
to the SN.  Bob's public key comes in the message (essentially
part of his "from" address).  The SN server correctly produces a
data capability for Bob and passes it down, as we agree, through
the membrane.

Now what?  Can Bob fetch Foo from the SN?  Of course if tries
to and the SN is on the partitioned capability system (E?)
where Foo resides then Foo will somehow have to pass over
to Bob across the network.

What about the case where SN is on a distinct machine on
the network?  Then when Bob makes the request on FMCSN
and passes in FMCFoo, Alice's membrane service ends
up passing Foo to the remote SN server.  If Alice's system is
a partitioned capability system then something like the DCCS
makes the Foo rights available by itself tabling Foo locally
and passing some sort of networked right to Foo across to
the SN.

Now Bob retrieves Foo by sending SNFoo to the SN server
and gets back a networked version of Foo - though not
FMCFoo as Alice's membrane attempt of course didn't
recognize the SNFoo 'capability' as a capability as it
went by.

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.

--Jed http://www.webstart.com/jed/ 

More information about the cap-talk mailing list