[cap-talk] request for comments on capability design

[Peter Amstutz]

Hello everyone.  I am in the process of designing a security model for a 
distributed object middleware I am working on called the Virtual Object 
System (VOS, http://interreality.org).  The present implementation uses 
an ACL-based security model which I am not satisfied with.  I've been 
looking into capability systems and I believe it to be a good fit for my 
design.  I should note that while I'm very interested in borrowing ideas 
from E, for various reasons actually using E in my application isn't 
practical (beginning with the fact that I'm using C++...)

My object system is based on the Actor Model; each object is logically a 
separate process with no shared state and communicates via message 
passing (in practice this will be tied together using a mix of OS 
threads and psuedo-continuations).  Objects are grouped into "sites".  A 
site generally represents the process hosting some set of objects; for 
example in a session between a client and server, each host is 
represented by a site.  Sites are identified with a public key which is 
used to authenticate that messages claiming to originate from the site 
are genuine.

Objects are replicated from the "server" to "client" (I use these terms 
for simplicity, it is actually more of a peer to peer system).  When the 
client interacts with the replicated object, messages are sent back to 
the server.  The server needs a way of deciding whether the client is 
allowed to perform an action on an object.  Also, for caching purposes 
it should be possible to store and retrieve object replications to 
persistant storage, so objects have a version, timestamp, and digital 
signature that it can use to verify what version it has, and if the data 
is authentic.

So, there are two types of authority in this system.  There is the 
authority to issue updates to a replicated object, and the authority to 
ask an object on another site to be changed.

The first type of authority seems pretty straightforward and a classic 
use of public key cryptography which I've already described.  Knowing 
the private key used to sign the communications is a very literal 
implementation of the notion of capability.

The second type of authority is more complex, and where I'd like some 
advice.  Just to get it out of the way, for reasons of efficiency and 
concurrency, I believe this requires a distict approach from the first 
type of authority, as distributing private keys on a per-object basis 
(granting authority to publish a change to the object) creates as many 
problems as it solves.

I presently envision a capability system that looks like this:

 * A fully qualified object identifier has three parts.  The site id, 
the public id, and the capability key.

 * The site id I discussed above.

 * The public id is the well known id for some object.  It allows you to 
compare two object identifiers to determine if they refer to the same 
underlying object.  Knowing the public id grants access to the "default 
policy" of the object, where the capability key == 0.

 * The capability key determines access.  When making a request, the 
client furnishes the capability key as part of the message.  The server 
receives the message, looks up the capability key in a table stored on 
that object, and fetches a security context.  The security context 
describes what permissions are granted to the capability as well as 
accounting information (such as who the capability originally given to).  
The security context determines if the message method is permitted on 
the object.

 * Revoking a capability is as simple as removing it from the object's 
capability table.

 * Reflection methods are available that allow the client to determine 
what methods are available via a given capability key.

 * A client can ask the object to issue a new capability key that is 
equivalent to or more restrictive than the one provided.

 * The typical use case for this system is for objects to be public but 
read-only to most users, and writable by a few.  Thus there is a 
provision for a default security context (allowing objects to be 
read-only or entirely inaccessable by default).

My question is, is this a real capability system?  It is modeled largely 
on my understanding of E from http://erights.org and from discussions 
with Kevin Reid on IRC.  I'm also curious how user, group and role-based 
abstractions are best built using capabilities; in particular in the 
situation where the user is on a public terminal, makes a transient 
connection to a remote service and must authenticate himself in order to 
gain access to his files.

Comments greatly appreciated,
Peter

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070516/15635066/attachment-0001.bin