Subject: Re: [e-lang] "Capability Myths Demolished" (was: Software security workshop)

From: Mark Miller <markm@caplet.com> · Date: Thu, 28 Nov 2002 12:34:13 -0800

Hal, great comments.  Let's discuss this in email first, before I attempt to 
revise the document.   

(I have revised the paper to put in anchors at the section headings, and to 
link to these anchors from the overview table at the beginning,  so that 
it'll be easier to cite individual sections.)

Regarding 
http://www.erights.org/elib/capability/duals/index.html#granularity ,  
Hal writes:

At 02:34 PM 11/27/2002 Wednesday, Hal Finney wrote:
>Both essays claim that while this equivalence might be true in a trivial
>mathematical sense, it overlooks the fact that ACLs are described in
>terms of principals, aka users, as the accessors.  

Actually, the point of my essay is to claim that this is one of a whole long 
list of ways in which these systems are not equivalent.  If this wasn't 
clear, then my essay is even more badly written then I'd feared.  Every one 
of the rows on the overview table is a non-equivalence.  All except the 
granularity issue are formal / mathematical differences.

>Capabilities on the
>other hand are owned by processes or programs, such that their ownership
>is at a finer level of granularity than ACLs.  

I was trying to say two things at once, so perhaps I said both badly.  The 
first, which you picked up on, is the purely quantitative issue of 
granularity: How big is the entity being authorized, and how many are there? 
The remaining "granularity" issue is another kind of static vs dynamic: 
Programs and classes are static.  Processes and instances are dynamic.  For 
terminological simplicity, I think we can all agree that a "class" is a kind 
of "program", and that a "process" is a kind of "instance" of a "program", 
so we can simply speak of "programs" vs "instances".

Your /etc/passwd file, no matter how long it is, lists only programs.   Java 
security properties files and the equivalent in "Netscape capabilities" 
lists only classes.  Code signing signs only programs.  "Posix Capabilities" 
lists only programs.  However, capabilities authorize individual instances, 
such that two instances of the same program may receive separate authority 
and be confined from each other.

OTOH, the distinction between program and instance, while qualitative, may 
still not be formalizable,  since data differences can be represented in code 
and vice versa. This real distinction is the one I call "human granularity" 
-- each individual separately authorized program is something some human can 
be assumed to have been separately aware of, and have made a decision about. 
This is not even conceivable as applied to instances, even large ones, 
because which instances will exist in not determined until runtime.

>Each user will in general
>be running multiple programs over a period of time and each could have
>its own set of capabilities, while they would in general all be treated
>the same in an ACL.
>
>The problem with that is that it is quite common on my Linux system,
>which I believe would be considered an example of a use of ACLs, to have
>more access rules than just those associated with users as principals.
>In particular, programs can be associated with accounts who don't
>correspond to any real individual.  In fact my /etc/passwd file looks
>like: [...]

At the section in question I state:
>What's a "subject"? In using the access matrix to model ACL systems, an 
>implicit assumption is made that "subject" corresponds to "user", "account", 
>or "principal", ie, is understood to have human granularity. [...]
>
>The appeal of the ACL model rests on the image of an administrator being 
>able to list subjects whose identity a resource's administrator can know and 
>reason about, ie, accounts, or other relatively static human-granularity 
>distinctions. [...]

Although principles-as-humans is the canonical ACL example,  by "human 
granularity" I am trying to say that it's an entity whose identity some 
human (with authorizing powers) is aware of.

>Anyway, I don't even know what most of these accounts are.  I didn't
>put them there, and they certainly aren't people who ever log in to
>my computer.  In fact, new ones seem to appear from time to time as I
>upgrade my system, which causes me some uneasiness from the security
>perspective, but most of them seem legitimate enough.

I am puzzled by the appearance of new accounts.  Where do they come from and 
how did you come to believe they are probably legitimate?   I think it would 
be interesting to examine this, in order to take apart my "human 
granularity" claim.

>Clearly most of these names are associated with programs and processes.
>They exist so that particular programs can be run with a specific set of
>access permissions.  They are a mechanism by which an ACL can be expanded
>beyond the simple model which seems to be expressed in these two papers.

By "expanded" are you referring to the automated expansion of the ACL of 
your system,  or the expansion of the ACL model represented by listing 
non-humans in this list.

>Now it may still be true that in practice, capability systems have far
>finer granularity even than my Linux system with its 20-odd accounts.
>I could imagine a Linux system with perhaps 100 or even 1000 accounts;
>but not one with a million accounts, and perhaps a capability system
>could have that many or more capabilities in action over a period of time.

If your /etc/passwd file is being automatically extended in ways you don't 
feel a need to review,  why couldn't you imagine an ACL system with a 
million accounts?  I think this question goes to the heart of the 
human-granularity issue?

>So the point may still be valid that capabilities lend themselves to an
>architecture with extremely fine-grained granularity of access, and that
>distinguishes them from ACLs.  But the exposition is a little unclear for
>users whose familiarity with ACLs comes from widely used free software.
>Perhaps the notes could address the issue of having accounts for the
>special use of particular programs.

Once this discussion settles some, I will clarify the paper.  Thanks! 

----------------------------------------
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