From: Mark Miller <markm@caplet.com>
Replying To: Zooko <zooko@zooko.com>
Date: Thu, 28 Nov 2002 15:23:34 -0800
Subject: Re: [e-lang] capability myths demolished!

At 05:56 PM 11/27/2002 Wednesday, Zooko wrote:
>Thank you for working on this document.  I think it is very important at this 
>stage in history that this paper be written.  Bravo!

Thanks! 


>I think that the essential question is "What authority is required in order to 
>implement this story?".
>
>I believe that ACLs can also implement the same text editor POLA story, but only 
>by using the superuser/administrator account to create a new principal, and 
>changing your UID to that principal before running the text editor.
>
>So, my current understanding is that ACLs do not offer *dynamic*, *non-higher-
>power-requiring* POLA.  (This is a bit of funny recursion.  ACLs can implement 
>POLA, but only caps can implement POLA while using the least necessary 
>authority.)

>This is a purely technical difference: whether or not you can dynamically create 
>a new protection domain without requiring superuser privileges.  [footnote1] 

This is a beautiful point, but as stated applies only to actual ACL systems. 

ACL systems don't necessarily require root authority to add accounts or to 
modify the ACLs, even though currently deployed ACL systems do require this.  
Ironically, the "Club" system several of us created at Xanadu -- now 
largely revived for Jonathan's OpenCM -- is an ACL design with decentralized 
account creation and authorization. shap

(A "Club" is an ACL that can list both subjects and other Clubs as members.  
Club X also designates which Club Y represents who has the right to read 
Club X.  And Club X designates which Club Z represents who has the right to 
edit the membership of Club X.  Note that Y or Z may be the same as X.)

Using the terminology of "...Demolished", the "Club" system aggregates this 
right-to-authorize by resource rather than by subject,  which is the 
difference I claim is fundamental. It turns out this difference is adequate 
to support your real point, since the subjects that have a set of 
authorities are not the ones that generally have the power to edit the ACLs 
of the resources they have authority to, and so cannot generally pass a 
subset those authorities to an entity they are invoking. Even in a 
decentralized ACL system, in order to engage in POLA, a subject must still 
have authorities vastly exceeding POLA. Once I figure out how to make this 
point in the paper, it'll be a powerful addition; thanks!


I know Jonathan has explained to me why he chose to use the "Club" ACL 
design rather than a capability one for OpenCM,  but frankly I remain 
confused on the matter. I think we would all learn by revisiting this 
question.  Jonathan? shap


[out of order]

>I think advantages of capability systems over ACLs can be grouped into three 
>categories:
>
>1.  technical
>
>1.a.  dynamic, non-higher-power-requiring POLA
>1.b.  endogenous verification [Shapiro99]
>1.c.  efficient revocation [Chander01] [footnote2]
>
>2.  engineering
>
>2.a.  unification of designation with authority (help the confused deputy)
>2.b.  unification of access and authorization [footnote3]

>I think that a lot of scientists out there would benefit from a closer look at 
>the topics in category 1, without the potential distraction of topics from the 
>other categories.

I like the idea of making this separation, but I don't understand why 2.a 
and 2.b are listed as engineering differences rather than technical ones.   
In any case, in "..Demolished" I am primarily trying to write the technical 
paper.


>2.c.  capabilities fit into the object oriented paradigm
>2.d.  practical POLA (because of 1.a, 2.a, 2.b, 2.c, ...)
>2.e.  practical confinement allowing untrusted code (because of 2.d)
>
>3.  political
>
>3.a.  not confining humans, not prohibiting delegation by humans
>3.b.  limiting your vulnerability to humans vs. identifying and controlling them
>3.c.  decentralization vs. centralization
>
>Of course, the reason *I* care so strongly about it lies in category 3.  I now 
>believe that unless a practical POLA system can be deployed (that allows people 
>to safely look at the dancing bears in their e-mail), that the world's computer 
>security problems will instead be solved by making it so that code only executes 
>after the operating system has checked in with central HQ to see if the 
>registered author of the code is in good standing with all of the relevant 
>authorities.

I like the engineering and political points a lot, but they don't belong in 
this paper.   I encourage you to write something up along those lines and 
I'll link to it.


>[footnote1]  Once you imagine extending an ACL system to allow such a thing, 
>you quickly see that you need other extensions to the ACL system to accomodate 
>this change.  It appears to me that after applying a couple such "obviously
>needed" extensions to the ACL system you have something that is isomorphic to a 
>capability system.

I doubt it.  As you incrementally fix the problems of an ACL system within 
the ACL paradigm, it's hard for me to see how you get farther then SPKI.   
Indeed, I gather that for some of SPKI's creators, this is how they think 
they arrived at the SPKI design. In particular, I don't see how to get to 
unified designation and authority by fixing and extending.


>[footnote2]  Yes, I *know* that [Chander01] says, in English prose, 
>[...] However I now see that they actually meant [...]

Given the sorry history of misinformation they're contributing to,  I'm not 
inclined to give them the benefit of the doubt until they clarify their 
position.  Please encourage them to do so.


>[footnote3] Hello!  I'm footnote 3 and I'm way down here.  The phrase "unifying 
>access and authorization" has often confused me, although I think I've got it 
>figured out now by reading "Capability Myths Demolished".  Perhaps a better 
>phrase would be "bundling authorization with meaning".

I've changed it from "Access and Authorization" to the active "Accessing and 
Authorizing".   Please reread the confusing parts and tell me whether this 
helps.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang