There are several models of rights out there - nyms, capabilities, bearer, account. One observation that has been made by Jeroen van Gelderen is that nyms (especially, SOX) as a model is a case of capabilities. What that means, beyond the superficial, has always been up in the air. The somewhat presumption was that SOX is a subset, or implementation of capabilities. Or, that SOX is capabilities hard-coded, whereas E, by contrast, is capabilities in the language.
The capabilities people (them) and the nym people (us) haven't really seen eye to eye on the lucidity of each other's documentation, so distance remained. Now, Jed Donnelley has broken ranks and cast his view of a definition of an Internet capability model.
With such a definition in hand, it's now possible to compare SOX, and any other nymous system, against the capabilities model. Best case, we'll show the original observation was right, and we can get on with the life of us and them. Worst case, we'll show it as being wrong, and we'll be forced to write our own definition.
That, I'll defer. For now, here's Jed's definition :
-------- Original Message --------
Subject: [cap-talk] Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.
Date: Thu, 29 Apr 2004
From: Jed Donnelley <jed@nersc.gov>
To: cap-talk@mail.eros-os.org
[big snip]
1. Definition of what you might call an Internet capability model. This
could be something along the lines of:
http://www.webstart.com/jed/papers/Managing-Domains/#s13
though I think modern encryption technology would suggest a
rework. The basic idea would be to define a protocol for sending
blocks of bits that:
a. Can securely represent the right to do anything that a service
(server) process might chose to make available.
b. Can be communicated securely - hopefully without contacting
the service process except of course when it is the source or
destination of the rights communication directly.
c. Is safe from evesdropping. That is, the form that the capability takes
when it's in, say, a processes memory space or in an email message,
cannot be used by any entity other than the owner of the memory
space (a process) or the email (presumably a person).
d. Extra points for including a rights reduction mechanism that doesn't
require permission from the server.
[another big snip]
Can we agree on that much?
--Jed http://www.nersc.gov/~jed/
_______________________________________________
cap-talk mailing list
cap-talk@mail..eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
The debate has way more content and quality than I can manage, and all I'm trying to do is tie down the definition of the capability. Here's some additional gems I have extracted:
1. Principle of Least Authority (POLA) is the underlying principle of design that points to capabilities [shap]. POLA is a principle, not a requirement, and capabilities is one way of designing according to POLA. Others are possible, and on first blush, SOX/nyms would also fit.
2. "The real magic of capabilities only arises with the addition of messaging between protection domains. Protected memory segments are just the primordial goo from which capability-based security emerged. [Tyler]" This seems to indicate that caps only make sense when dealing with administrative domains - the ability to move caps from one place to another where the two places aren't owned or managed under the same set of interests.
3. Capabilities and their representations are different. Capabilities may be passed from person to person, but their representations should be of a non-secret form [Alan]. That is, if Alice sees Bob's cap1 she doesn't acquire it.
The question here is ... why is an over-shoulder attack considered a serious threat?
4. There's a serious amount of confusion (in my mind at least) as to whether "confinement" is an underlying and foundational requirement, or just a concept that is equally seivelike in reality. Confinement seems to mean that within a domain, nothing leaks out except by expected and authorised channels. OK, is that it? That's what we've got now - nothing leaks out, except it's buggy and stuff leaks out. Or something.
5. "Right to communicate your capability" seems to exist [Jed]. This makes sense, as once you have a cap, you can proxy its use. Yet it flies in the face of confinement. So far, no end to the contradiction.
6. Audits have been suggested [David] - which opens up a new line of investigation (FC layers 4,5) that may put more flesh on the skeleton.
7. Is there a difference between OO objects and capabilities? It's a definate maybe, so far. See zooko's response on this issue, and David's remarks.
Posted by: Iang at May 11, 2004 10:54 AM