[cap-talk] Argument for capabilities as data in NLTSS

[Jonathan S. Shapiro]

On Mon, 2007-07-16 at 15:38 -0700, Jed Donnelley wrote:
> Jonathan S. Shapiro wrote: 
> > On Mon, 2007-07-16 at 11:28 -0700, Jed Donnelley wrote:
> > > 2.  If we were going to implement a serialization
> > > protocol for network capabilities, then any computers
> > > that had access to the network would have access to
> > > what amounts to capabilities as data for any capabilities
> > > that are distributed on the network.
> > >     
> > 
> > This seems to ignore the possibility of network layer encryption and of
> > mutually authenticatable nodes. Automatically bootstrapping the latter
> > has only recently become possible, but it clearly could have been done
> > by hand at the time of NLTSS. Cryptography, of course, was then well
> > established.
> > 
> >   
> I think perhaps the issue is more a lack of clarity in my description
> of
> the argument.  When I say "any computers that had access to the
> network would have access to what amounts to capabilities as data
> for any capabilities that are distributed on the network." I didn't
> intend to imply that computers which could "snoop" the network
> traffic would get access to the permissions provided by the
> serialized capabilities, but rather that when any computers on
> the network properly received such serialized capabilities
> (e.g. across encrypted communication facilities), they would
> then be dealing with what amounts to capabilities as data.
> 
> Does that answer this?:
> 
> > So this assumption seems transparently wrong. What am I missing here?

Yes. You seem to be engaged in a confusion about layering.

When I write that a protected capability system is one in which data is
never interpreted as authority, I really mean "data provided by
application code". There is inevitably a layer of the runtime system
where the inner representation of capabilities is known and deemed
binding.

Going back to your example above, let us now assume transport layer
encryption (or equivalent) and mutual node-OS authentication.

At that point, I take the view that what we have going on here is an
internal communication performed by a distributed trusted runtime. I
agree with the statement that any participating node has access to any
capability that it receives, but this is still a matter between the
runtime and itself. It does not seem to have any obvious bearing on the
question of whether capabilities, as viewed by the application, should
be protected.

I have more to say on this, but it's a different direction, so I'll take
it up separately.


> > > 3.  Why limit processes that run under some OS on
> > > a network to having less access than computers that
> > > run on the network?  By providing less access you
> > > are really fooling yourself if you think that you are better
> > > protecting your capabilities, because those capabilities
> > > will still show up as data in the computers on the
> > > network.
> > >     
> > 
> > It is fairly clear that we can protect supervisor memory from incursion
> > by applications, so there is a clear distinction to be made between raw
> > capabilities appearing in supervisor memory vs. raw capabilities being
> > accessible to user-mode code.
> > 
> > So this assumption also seems transparently wrong. What am I missing
> > here?
> > 
> >   
> What I am arguing here is that once you launch a capability out onto
> the network, even
> if you use end-to-end encryption of the channel, you have effectively
> no control over
> the computer that receives such a capability.

This is what I thought you meant. What you say is true if you send that
capability to an untrusted node. If you do that, you are pretty much
hosed eight ways from Sunday. The problem with the statement taken as a
design criteria is that it excludes the possibility of mutually trusted
nodes. If the target node is untrusted, the presence of link encryption
is of course irrelevant. But the question I would ask in response to
this proposition is: "Well why the hell did you send a clear-text
capability to an untrusted node?"

>   It may be a capabilities as descriptors
> system where the capability is essentially emulated for remote
> execution...

I claim that this isn't really possible. In this scenario, what you are
doing is a higher-level protocol over an encrypted session. It is a
matter between cooperating applications having nothing (or very little)
to do with the capability layer. Also, the session is severable.

> or it may just deal with whatever serialized
> form of the capability it receives and try to make use of it.

Game over if you allow that.

>   From the viewpoint of
> the domain sending the capability the relevant receiving domain of
> trust at the other
> end is the whole computer system, not just what might be imagined as a
> single
> confined domain.

This depends heavily on whether you think you can bootstrap trust
between TCBs connected by a network. I think it is a question of where
you define the system boundary to be. I claim that capabilities must not
ever leave their system of origin, but it is possible for a single
system of origin to be implemented by a distributed implementation.

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC