<html>
<body>
At 04:24 AM 12/6/2007, Toby Murray wrote:<br>
<blockquote type=cite class=cite cite="">Hi all on cap-talk and
e-lang,<br><br>
(apologies for those who subscribe to both lists)<br><br>
We've just had accepted that may be of interest to many on these
lists.<br><br>
"Non-Delegatable Authorities in Capability Systems"<br>
By Toby Murray and Duncan Grove<br>
(to appear in the Journal of Computer Security)<br><br>
<a href="http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/NDA.pdf" eudora="autourl">
http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/NDA.pdf</a><br>
<br>
The paper speaks to the heart of the "delegation" issue that
has been<br>
debated many times over the years on these mailing lists. I think it<br>
represents a so-far unexplored part of the debate that I hope will
be<br>
reignited at this point. I'll let the abstract do the
talking.</blockquote><br>
Toby and Duncan - Sorry to take so long to get back to you about
your<br>
Non-Delegatable Authorities paper. It took me a while to read
through<br>
the paper and what I considered to be the important references.
I<br>
felt I needed to communicate a bit with Toby privately just to
insure<br>
that we're both comfortable debating the topic on cap-talk with no<br>
hard feelings for strongly felt positions.<br><br>
As Toby and Duncan note in the above paper, I believe that
preventing<br>
delegation is not only harmful for programability (and thus for
security)<br>
but is also unnecessary - as he refers to my early Managing Domains
paper:<br><br>
J. E. Donnelley, "Managing Domains in a Network Operating
System" (1981)<br>
Proceedings of the Conference on Local Networks and Distributed
Office<br>
Systems, Online, pp. 345-361.<br>
<a href="http://www.webstart.com/jed/papers/Managing-Domains/" eudora="autourl">
http://www.webstart.com/jed/papers/Managing-Domains/<br><br>
</a>My position on efforts at delegation blocking have strengthened<br>
somewhat since I wrote the above paper, significantly since<br>
I've been active on the cap-talk list (2004), and even more<br>
since our Horton work. I'll lay out my arguments here.<br><br>
<br>
1. First regarding unnecessary: Let's consider the value<br>
section of the Non-Delegatable Authorities Paper (hereafter<br>
NDAP) paper, 1.2. I argue that from the viewpoint of access<br>
control, communicating a membraned capability in place of a<br>
non-delegatable capability provides all the value with more<br>
control. At the point that Alice's code is patched after<br>
being discovered as vulnerable, the membrane can be revoked<br>
and reissued to Alice. This of course not only controls<br>
access to the capability itself, but to any capabilities<br>
communicated through the capability - a point I didn't see<br>
addressed in the NDAP.<br><br>
I don't believe membraned capabilities can be combined<br>
to result in rights amplification because the membraned<br>
capabilities aren't the same as the capabilities<br>
required for the rights amplification. Perhaps we<br>
can look into this further if this is an issue.<br>
This can depend a bit on which capability is invoked<br>
for rights amplification and how. Perhaps it would<br>
be helpful to have a specific instance of rights<br>
amplification (which I guess depends on some EQ or<br>
MyCap? mechanism?) to pursue this further?<br><br>
Regarding accountability, I argue that a mechanism like<br>
Horton:<br><br>
Mark S. Miller, James E. Donnelley, and Alan H. Karp,<br>
Delegating Responsibility in Digital Systems: Horton's<br>
"Who Done It?", presented at the 2nd USENIX Workshop on<br>
Hot Topics in Security (Hotsec '07), Boston, August 6, 2007.<br>
<a href="http://www.webstart.com/jed/papers/horton.pdf" eudora="autourl">
http://www.webstart.com/jed/papers/horton.pdf</a><br><br>
provides accountability with more flexibility. From<br>
my perspective the accountable entity for actions<br>
enabled by a capability bears no necessary relationship<br>
to a particular code segment that might be the first<br>
active object that receives a communicated capability.<br>
With Horton any capability can be set up so that<br>
other capabilities communicated through it have<br>
their accountability (accountable entity label)<br>
transformed (or not). If Alice needs to modularize<br>
her code, she can do so and act on a capability<br>
labeled appropriately as a single accountable entity<br>
(or not).<br><br>
Regarding accountability in the real-world, I argue<br>
that such accountability is tied to responsibilities<br>
that come as positions or roles, not to individual<br>
actors. If a secretary or administrative assistant<br>
needs to be delegated the authority to act on behalf<br>
of a responsible party in some circumstances, it<br>
can be done. The responsible party is still<br>
accountable and the action by the delegated entity<br>
is logged and can be controlled (e.g. as with<br>
Horton). This flexibility is often vital - as it<br>
is in programming systems.<br><br>
<br>
2. Second with regard to harmful: This is the<br>
main body of my concern. Unfortunately I'm not<br>
sure I have terminology appropriate to express<br>
my main concern in this area. I'm hoping others<br>
can help.<br><br>
Any computer system consists of segments of<br>
sequential code in separate or shared domains<br>
that communicate. At any point in time one<br>
can draw boundaries anywhere in the system to<br>
define what is included - outside the system<br>
considered I/O and inside the system considered<br>
internal communication.<br><br>
What I believe is vital for programability of<br>
computer systems is the ability to at any time<br>
take what was previously a single code<br>
segment in a single "domain" (protection<br>
region/object) and break it into multiple<br>
objects (I'll stick with the object<br>
terminology as possible). It should also<br>
be possible to make use of other code in<br>
what is potentially a separate object through<br>
communication. In a private instance of this<br>
message to Toby I referred to this ability<br>
as "composability and decomposability". I'm<br>
not sure what the right terminology is, but<br>
I feel it is vital.<br><br>
From my perspective non-delegatable capabilities<br>
(object references) break this fundamentally<br>
important property of programming in computer<br>
systems.<br><br>
Consider the case where "Alice" is the active<br>
object that has somewhat limited trust by<br>
whatever program (Bob) that is communicating to<br>
Alice so that the communicated permissions are<br>
communicated as non-delegatable capabilities.<br>
Later it's decided that the programming of<br>
Alice needs to be improved and the planned<br>
improvement is to break the code that<br>
originally composed Alice into multiple<br>
distinct objects. What was previously<br>
shared references to a single object within<br>
Alice now requires Alice to communicate some<br>
objects to a new part of Alice. How can this<br>
be accomplished if one of the permissions<br>
that needs to be communicated is the one<br>
that Bob didn't fully trust Alice with?<br><br>
It seems that Alice's only alternative is<br>
to proxy such access to what has now become<br>
a separate object within what was formerly<br>
her single "domain"/object.<br><br>
The same sort of problem arises if Alice<br>
might need to make use of another existing<br>
object to better modularize her code.<br>
Somebody implements a new object that<br>
modularizes just what Alice needs, but<br>
alas for poor Alice she has a non-delegatable<br>
capability that she needs to send to it?<br><br>
<br>
One of the strengths that I believe we are<br>
"playing" to with the object/capability model<br>
is the similarity - even the essential identity<br>
of the model - with the object programming model.<br>
How many object programming models are there<br>
that you know of where references in some cases<br>
can't be communicated as parameters?<br><br>
The disaster that seems to befall a programming<br>
system with non-delegatable object/capabilities<br>
is that it seems to have to always be prepared<br>
to communicate by proxy. If it has a way to<br>
test for non-delegatability then it does the<br>
test and communicates as automatically as possible<br>
by proxy. If it doesn't have such a test then<br>
it seems to need to delegate by proxy at all<br>
times - just in case it happens to have been<br>
passed a poisoned object reference.<br><br>
This is nonsense. No object programming model<br>
would (should) put up with it. If anybody knows<br>
of such object programming models, I'll be<br>
quite interested to hear about them and how<br>
they manage to function.<br><br>
<br>
3. Regarding the implementation: It's a<br>
neat trick, but a neat trick used for the worse<br>
sort of programming IMHO. It takes a subtlety in<br>
the language and exploits it to defeat the basic<br>
communication paradigm of the language and model.<br>
To me this implementation argues more for fixing<br>
E than it does for non-delegatable objects. I<br>
say hurray for EROS (KeyKOS, etc.) that their<br>
implementation is faithful to the notion that<br>
all permissions are represented by object/capabilities,<br>
even the permission to return from a call.<br>
Besides being valuable for implementations<br>
(e.g. the ability to store return capabilities<br>
in a directory the way the DCCS implementation<br>
did) it just generally provides all the value<br>
of objects for the return authority. If<br>
capabilities are good for one authority and<br>
good for an authority model then I argue<br>
that they are good for all authorities.<br><br>
One further note on the implementation: If the<br>
idea of a non-delegatable capability is good and<br>
needed (as I argue not), then it seems to me<br>
the thing to do is to make it visible and<br>
always available. This can be done in a relatively<br>
straight forward way as DEMOS did with a<br>
"pass once" access right that is turned off<br>
when communicated, e.g.:<br><br>
F. Basket, J. H. Howard, J. T. Montague,<br>
<b>"Task Communication in Demos",</b> Proc. of the<br>
Sixth Symposium on Operating System Principles,<br>
Purdue University, 1977, pp. 2331.<br><br>
<a href="http://portal.acm.org/citation.cfm?id=806544&dl=ACM&coll=GUIDE" eudora="autourl">
http://portal.acm.org/citation.cfm?id=806544&dl=ACM&coll=GUIDE<br>
</a><may not be original to that paper/system, I<br>
just remember it there and know of no previous<br>
reference><br><br>
Of course doing so makes it a primitive<br>
of the capability implementation. I'm not<br>
advocating for this because I'm horrified by<br>
it [as I was in Demos], but I do think that<br>
direct approach is better than drawing out<br>
some hidden lack in the capability implementation<br>
and exploiting it for this purpose.<br><br>
By providing a primitive that will turn any<br>
object reference into a "pass once" reference<br>
one can easily support such non-delegatable object<br>
references. Of course doing so becomes a visible<br>
system primitive. The fact that such a mechanism<br>
may not be pure object/capability (just "capability")<br>
I argue is relatively insignificant compared to<br>
the cost of the approach you seem to be suggesting.<br>
As I say, I believe doing so (either approach) would<br>
utterly destroy the object programming model, but<br>
better even that than to hide what's being<br>
done in such an obscure way and still expect<br>
it to be available for use for all object<br>
reference communication - IMO.<br><br>
<br>
4. One minor point I'll mention with regard to the<br>
references: The only reference that NDAP uses<br>
in support of the "loose capabilities" argument is<br>
where you say, "the inability of capability systems<br>
to prevent delegation by capability passing hinders<br>
security because it increases the burden of trust<br>
(as argued in [31])", referring to:<br><br>
Dan S. Wallach, Dirk Balfanz, Drew Dean, and Edward<br>
W. Felten. Extensible security architectures for Java.<br>
In Proceedings of the Sixteenth Symposium on Operating<br>
Systems Principles, pages 116{128, 1997.<br><br>
where they do consider the capability model as<br>
one type of a security 'extension' architecture<br>
for Java (does this end up being something like<br>
vats for Joe-E?). Since this is the heart of the<br>
value side of the equation for non-delegatable<br>
capabilities, I though that specific reference<br>
particularly important. I'd like to aggressively<br>
go after any such arguments until I (we) am (are)<br>
convinced that there is some fundamental truth to<br>
them or manage to see through/shoot down their<br>
arguments.<br><br>
In the case of this paper:<br><br>
<a href="http://www.cs.princeton.edu/sip/pub/sosp97.pdf" eudora="autourl">
http://www.cs.princeton.edu/sip/pub/sosp97.pdf</a><br><br>
I believe the crux of the argument is in section<br>
4.3 where they refer to the issue of "confinement<br>
of privileges". They refer to Lampson's famous<br>
(appropriately?) note:<br><br>
LAMPSON, B. W. 1973. A note on the confinement<br>
problem. Communications of the ACM 16, 10 (Oct.),<br>
613–615.<br>
<a href="http://www.cs.cornell.edu/andru/cs711/2003fa/reading/lampson73note.pdf" eudora="autourl">
http://www.cs.cornell.edu/andru/cs711/2003fa/reading/lampson73note.pdf</a>
<br><br>
The above note concerns itself only with confinement<br>
of information, not confinement of the propagation of<br>
privileges. As such that reference seems to me<br>
inappropriate in this context.<br><br>
Beyond that reference, the authors of the Java<br>
extensibility paper simply state that, "It should<br>
not generally be possible for one program to<br>
delegate a privilege to another program (that<br>
right should also be mediated by the system)."<br>
without supporting argument. As noted in this<br>
message I believe that position is seriously<br>
flawed. Of course in the object/capability<br>
model the authority to delegate requires<br>
a capability to delegate over and that is<br>
exactly where the only system "mediation"<br>
'should' be applied as that matches up<br>
exactly with what can be enforced regarding<br>
communicating conspirators.<br><br>
In the above section 4.3 they say, regarding the<br>
"inalienable right to communicate a capability"<br>
(my term) that:<br><br>
"This is the fundamental flaw in an unmodified<br>
capability system; two programs which can communicate<br>
object references can share their capabilities without<br>
system mediation. This means that any code which is<br>
granted a capability must be trusted to care for it<br>
properly."<br><br>
Uh, of course. Isn't this obvious? That's what you<br>
mean by granting a code a capability - trusting it<br>
with the capability. Of course any sort of "system"<br>
mediation can be applied in the capabilities that<br>
are granted for communication. E.g. if all such<br>
capabilities include Horton responsibility re labeling,<br>
then any communicated capabilities will be so<br>
re labeled. Any needed "system" mediation can be<br>
similarly applied to any capabilities granted<br>
for communication.<br><br>
Then they say:<br><br>
"In a mobile code system, the number of such trusted<br>
programs is unbounded. Thus, it may be impossible to<br>
ever trust a simple capability system."<br><br>
This really floors me. If the above reasoning is<br>
sound, then we have some very serious problems with<br>
the capability model.<br><br>
Firstly, if the number of programs communicated to<br>
by one program is indeed unbounded (e.g. the case<br>
of no confinement that Toby and Duncan focus on),<br>
then it seems to me that the fundamental trust in<br>
the program given the original permission with this<br>
wide ability to communicate needs to be pretty high.<br>
It seems obvious to me that if I trust a program<br>
with a permission (e.g. RW access to a file) and<br>
that program can communicate widely, then the only<br>
thing between me and widespread access to my file<br>
is my faith in the correct operation of that program.<br>
As we know from the communicating conspirators example:<br><br>
<a href="http://www.erights.org/elib/capability/conspire.html" eudora="autourl">
http://www.erights.org/elib/capability/conspire.html</a><br><br>
(Is there a reference for this description?)<br><br>
where MarkM says:<br><br>
"Can Alice arrange to prevent Bob from giving Mallet<br>
the Power? The answer is simply no."<br><br>
<br><br>
I'm sure you can tell this is something that<br>
I feel strongly about. I think this is exactly the<br>
sort of topic that is important to discuss on<br>
cap-talk (the "loose caps" concern being high<br>
on the list of concerns about object/capability<br>
systems). I'm a bit worried that there is a paper<br>
accepted for publication on the topic before it<br>
is thoroughly vetted on the list (unless I missed<br>
that discussion). Of course there are topics on<br>
which reasonable people can simply disagree, but<br>
I believe this one is so fundamental to the<br>
object/capability model and to object programming<br>
in general that I'm afraid a fundamental rift on<br>
this topic may split the community.<br><br>
I sincerely hope we can work out the issues on<br>
this topic. I wonder if it would be worthwhile<br>
to seek out any other places that seem to make the<br>
"loose capabilities" argument and examine their<br>
reasoning. I can see the intuitive appeal of<br>
this argument. It's just that this is a place<br>
where I believe our intuition is simply wrong.<br><br>
I believe that with the sort of membrane mechanisms<br>
we have in appropriately extendable capability<br>
systems (e.g. the E examples such as the membrane<br>
instances and Horton) we have available as much<br>
protection as we can get for communicated capabilities<br>
in the face of communicating conspirators. Asking<br>
for more, particularly in the form of "non-delegatable"<br>
capabilities, I believe to be seriously unwise in<br>
that it breaks a fundamentally important value in<br>
the programming system and gains nothing in return.<br>
<x-sigsep><p></x-sigsep>
--Jed
<a href="http://www.webstart.com/jed-signature.html" eudora="autourl">
http://www.webstart.com/jed-signature.html</a></body>
</html>