[cap-talk] Reflections on capability levels and confinement trust

[Jed Donnelley]

cap-talk,

We've put quite a bit of attention into distinguishing the various 
levels of capability implementation, language (e.g. E), operating 
system (e.g. EROS), and network (e.g. YURL).

I'd like to ask a question or two about these levels, possibly to 
rattle some cages.  In particular the venerable operating system 
level.  We've recently seen a number of resource issues pop up at the 
operating system level.  Perhaps these issues appear at other levels 
in different form.  However, that discussion got me thinking about 
just what value is essentially added with capabilities at the OS level.

One could argue that nothing essential is added at the OS level as 
there have been a number of systems implemented that use network 
level capabilities at the OS level (e.g. the Monash systems, Amoeba, 
NLTSS to name a few).  I think this understates the case for OS level 
capabilities.  For example, I don't think any of those systems that 
adopt network level capabilities at the OS level support confinement 
(in Jonathan's sense - explicit confinement not including covert channels).

It seems to me that the confinement value is added at the OS level by 
requiring whatever form the "invoke" call takes to have a valid 
capability to invoke that designates a communication channel to the 
server of the object.

I wondered if it's possible to use network level capabilities at the 
OS level and get the OS to require them to be 'valid' in a 
communication sense, but then to leave all the rest of the "work" of 
the capability implementation to the client/server protocols at the 
network level.  So suppose, for example, we have a capabilities as 
data protocol (e.g. cryptographically signed capabilities, perhaps 
the delegation protocol that we've discussed at that level) but that 
we want to try to extend it minimally to the OS level to get 
confinement out of it?

The question I'm interested in answering is, What would/should/could 
the OS implementation of the "invoke" call minimally provide at the 
OS level to support confinement (and hopefully the other capability 
values that we've come to know and love) when used with what amount 
to network level capabilities?

This gedanken "invoke" call is given a network level capability 
(let's say a cryptographic capability as data) to invoke and some 
other capabilities and data to communicate.  How would our putative 
minimal OS decide whether or not to allow the communication, and if so to who?

One approach that occurred to me is to have such an OS keep a 
public/private key pair for each process and keep at least the 
private key outside the process so that it can only be used in 
operations requested through system calls.  With such a scheme one 
could imagine that capabilities incoming to the process would be 
signed with the private key of the process by the OS (confinement 
kernel?) to indicate that they are valid capabilities (with whatever 
network communication designation they include - e.g. an IP address 
or DNS name and perhaps the public key of the receiver).

Given such an approach I can imagine how functions like the "gate 
keeper" functions (the ability to create new capabilities serviced by 
the process) and initialization and communication could be done.  I 
can imagine (I'll be interested to hear if others can't ;-) how an 
internally self consistent system could be developed that has most 
(all?) the values typically associated with an OS level 
implementation of capabilities, including confinement.  Capabilities 
can really only be created by the OS in accord with it's policies (by 
signing capability designations including network address information 
and a public key).

What then interests me is how such a system could interact with other 
systems on a network and maintain it's confinement value (and other 
values typical of a descriptor based capability OS - assuming you buy 
into my dreaming that far).  In some ways such a system is the 
network dual of the Distributed Capability Computing System:

http://www.webstart.com/jed/papers/DCCS/

In the DCCS an OS level capability system is extended to a 
network.  In this case a network capability system is integrated into 
an OS.  In both systems there's a bit of a bootstrapping issue.  One 
could imagine getting around that by priming the pump with some 
process able to communicate internal capabilities directly on the 
network.  One could use such a mechanism to, for example, set up 
something like the give and take directory sharing mechanism that I 
described (e.g.:

http://www.eros-os.org/pipermail/cap-talk/2006-December/006052.html

) that can share between users on systems separated by a network.

Suppose I've bootstrapped such a system.  Now I as a user have some 
capability to another system on the network (e.g. some person put it 
in their "take" directory, effectively publishing it globally).  I 
start a process and give it that capability as part of it's 
initialization.  My process invokes the remote capability and gets 
some capability back.  In the process of receiving that capability my 
kernel uses the processes private key to sign it's contents, thereby 
validating some network address who knows where.

In general if I give a capability to a process I'm implicitly giving 
it access to the capabilities it can get through that initial 
capability (what's been referred to as the distinction between the 
simple permission and the authorization that it conveys - e.g through 
multiple invocations).  In the case of this remote capability, 
however, it seems as if I might be compromising confinement in even a 
stronger sense.  For example, suppose this remote capability allows 
me to listen on a general Internet TCP port or connect to same?  In 
that case confinement is effectively gone.

Still, I could have set up such an "Ingternet" capability locally and 
communicated it to my process.  Buyer (delegator) beware?  Is there 
really anything better that we can do than that described above?

I'll be interested to hear if anybody is willing to read and comment 
on this minimalist OS approach, specifically with regard to what 
values it may miss from modern capability OS efforts like EROS.  I'm 
interested to know what facilities there are that might exist in a 
system like EROS that couldn't exist in such a network capability 
mechanism with a minimal OS - perhaps considering how any such 
facilities map or fail to map to the network level.

Thanks for your indulgence in my reflections.

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