[cap-talk] Don't understand capabilities

[Charles Landau]

At 4:11 AM +0100 10/27/06, lists at notatla.org.uk wrote:
>OK, let's list some attempts at a definition of a capability and
>then some examples and see how correct and consistent they are.
>
>
>Definitions
>===========
>D1  Jed's words:
>       "All capabilities are is communicable references to objects that
>        convey both designation (identify the object) and permission (grant
>        some sort of access to the object)."
>     Plus a supplement derived from the rest of his mail I'm replying to:
>D1.s1
>     There's a reason to think the capability is the _only_ way to affect the
>     underlying object.
>
>     Whether it's fair or not I'm going to take this definition as literally
>     as I can and see where it leads.  So if you left out something 
>as not worth
>     stating then I'm interpreting this definition as not including it.  You
>     said it was "VERY simple" and I'm going to act as if I believe you.  :)
>
>D2  The article http://www.eros-os.org/essays/capintro.html is more of a
>     description but I'll try to use it as a definition (largely ignoring the
>     warning "This essay is informal. My goal here is to get across the core
>     of an idea").
>
>
>D3 The Wikipedia article you referenced
>    http://en.wikipedia.org/wiki/Capability-based_security
>    says
>       "A capability is defined to be a protected object reference 
>which, by virtue
>        of its possession by a user process, grants that process the 
>capability (hence
>        the name) to interact with an object in certain ways. ..."
>    (Is this a reference that's protected or a reference to a 
>protected object?)

It is a reference that is protected.
More specifically, it is non-forgeable, and its implementations 
details are non-readable by the user of the capability.

You might also say that the object is protected, in the sense of D1.s1.

>
>D4  This starts like D1:
>          "All capabilities are is communicable references to objects that
>           convey both designation (identify the object) and permission (grant
>           some sort of access to the object)."
>D4.s1  There's a system and only inside this system is the 
>capability meaningful.
>        (Kind of like a function definition has a domain as well as a 
>way to calculate y from x.)
>D4.s2  The system contains a part that requires the capability to 
>access the object.
>        (I'll call this "the customer".)
>D4.s3  The system contains a part that has some other means to 
>access the object, and uses the
>        capability data in a different way from "the customer".
>        (You used the term "the servicer" and I think this is that.)
>D4.s4  The capability is large and randomly-generated to prevent it 
>being guessed either from
>        scratch or by modifying another capability.
>        (The capability is being used as a security mechanism.)

What is the source of D4?
It seems to suggest that a capability is data.
If you want to avoid confusion, I suggest you avoid this definition.

>Examples
>========
>
>E1 An URL may be a capability.  This one for example (in a 
>non-indexable directory):

E1 is a complex example. Basically, a URL is a capability only if you 
assume it is unguessable (non-forgeable) and its internal structure 
(bits) are not observed by the user.

>E4 A file descriptor may be a capability, as seen in
>       http://en.wikipedia.org/wiki/Capability-based_security
>    After a successful call to
>        int fd=open("/etc/passwd", O_RDWR);
>    the descriptor is called a capability.
>
>    Now this gets to the meat of my post and where I know I'm 
>confused when I try
>    to interpret this article.  In fact I'm going to attempt several 
>interpretations,
>    that have flaws and are here to be debunked.
>
>...
>
>    E4.i3      A blob of kernel memory is the capability and 
>communication of it means
>               descriptor-passing.  This seems closest to what it 
>literally says.

This is the correct interpretation.

>    Tested by D1:   This fails my test of "VERY simple".

We are not saying the implementation is simple. The architecture is 
simple from the user's point of view. You can invoke or pass the 
authority just by identifying it (with an int fd).

>    Tested by D2:   Maybe passes - but the servicer does get to know 
>who the user is.

In example E4, the servicer is the kernel, which knows everything, 
but the kernel does not care who the user is.

>    Tested by D3:   This should pass if this is really the meaning of 
>the article.