[cap-talk] request for comments on capability design
tetron at interreality.org
Wed May 16 17:24:58 EDT 2007
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
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
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
* Revoking a capability is as simple as removing it from the object's
* 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 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
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070516/15635066/attachment-0001.bin
More information about the cap-talk