[Cryptography] Capability Myths Demolished was: Do capabilities work? Do ACLs work?

[Bill Frantz]

On 2/15/15 at 5:03 AM, leichter at lrw.com (Jerry Leichter) wrote:

>Someone earlier mentioned the paper Capability Myths Demolished
>(http://zesty.ca/capmyths/usenix.pdf), a paper a read a while 
>back and re-read now.  It's a nice piece of work, and makes 
>some excellent points, but I've always felt that as what 
>amounts to a polemic,

Well yes, there is an overtone of annoyance that these myths persist.


>it cheats a bit, in two different ways:
>
>1.  It's response to complaints that "ACL's can do X but 
>capabilities can't" is "oh, but that's because we have this 
>neat extension to the capabilities model and a new 
>implementation that lets them do X"; but it never considers the 
>possibility that those favoring ACL's might also be able to 
>play the same game. (For example, VMS, when it computed the 
>list of predicates to be checked, took not just the current 
>accessed object's own ACL, but merged in ACL's for a 
>hierarchical list for - just going from vague memory now - the 
>process, the group, and even a system-wide list.  That's how an 
>ACL associated with the currently running program became 
>effective.  The system-wide list could be used to produce 
>effects similar to Unix run levels.)

Well, the way I read it is that the paper is comparing various 
misunderstandings of the capability model with the actual one, 
the object capability model. Note that Hydra was built in 1971 
and the Cambridge CAP computer was built in the 1970s as was 
KeyKOS. Given the early appearance of object capability systems, 
I think the paper's limiting the use of "capability" to object 
capabilities is reasonable given this history.

There are no extensions to the object capability model used in 
that paper.[1]


>2.  It cherry-picks examples for which capabilities do well and 
>ACL's don't.  There's nothing there like my Area 51 workers example.
>
>In fact, you can sometimes take duals of their examples to 
>produce examples that cut the other way.  The Confused Deputy 
>problem is based on a timing ambiguity about which object an 
>ACL is supposed to apply to; but there's a dual issue in the 
>Area 51 problem, which has a similar timing ambiguity about 
>which actors are in the set.

Well, I think I addressed the Area 51 problem, but I'll wait for 
your comments. In any case, they mention so many security 
policies that capability systems support and ACL systems don't, 
for example least privilege, it is clear to me which is a better 
platform, but I've felt that way since the 1970s. :-)

Cheers - Bill

[1] The easiest way to think about the object capability model 
is to use an object oriented language as an example. Consider 
Java. Java references are capabilities. If we get rid of the 
parts of the Java library which provide ambient authority, for 
example the File class or the network classes, Java programs are 
constrained to obey the object capability rules:

     The only way you can get a capability is to be born with it,
     be passed it, or create the object it represents.

     The only thing you can do with a capability is invoke it or
     pass it in a capability invocation.

Note that in a system where we have removed the ambient 
authority, we still have to provide the functions that were 
accessed through ambient authority to programs. The E language 
passes these authorities to the "main" entry point. If you want 
to ensure that an E program can't access the file system, start 
it without the file system access capability. If you want to 
keep it off the network, don't give it the network access capability.

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032