[cap-talk] Don't understand capabilities

[Marcus Brinkmann]

At Fri, 27 Oct 2006 11:57:52 -0400,
Sandro Magi <naasking at higherlogics.com> wrote:
> 
> Marcus Brinkmann wrote:
> > Actually, one of the most straightforward ways to name a book is to
> > physically operate on it. 
> 
> I'm puzzled. By "name a book", you seem to imply something other than
> "my copy of 'Catcher in the Rye'", which clearly does not operate on the
> book.

By naming I mean any way to identify, designate or locate an object,
be it describing it verbally, pointing to it with your finger or
grabbing it to open it.

> > I don't think that brands provide quite the same type of naming I
> > mean.  In the real world, I do not need somebody any authority to be
> > able to name an object.
> >   
> 
> You don't need any authority on the object to hold its brand. If I
> understand it correctly, a brand is just a GUID, not a reference to the
> object itself.

I was thinking of EROS brands, which uses capabilities (that do not
actually implement any operations) as unique unforgeable identifiers.

If you want to introduce another concept like GUID, I think you should
describe how it can be fitted into a capability system so I can try to
understand it.
 
> >> You still have to be able to touch the book to actually operate on it
> >> (open it, read it, burn it, etc.). That's a capability. Any disagreements?
> >>     
> >
> > Sure, that's a capability.  But the world is larger than that.
> >   
> 
> Right, but I thought we were concerned with the world of access control. :-)

I thought we were concerned about understandability of capability as a
concept :)
 
> If we're dealing with the world at large, then sure, designation and
> authority might be separate in some cases, and can perhaps even be
> useful when separated. When actually producing side effects however, you
> seem to actually need the "capability" to do so (in any sense of that
> word). I'd be interested to hear counterexamples.

It seems we agree.  I don't think any counterexamples are needed to
make my point.

As a case in point, I think in the real world the confused deputy
problem is also for real.  Typical human engineering attacks are
calling people up with some background story, and asking them for the
information you want (a password, a secret document, whatever), to
which they have access.  If you present your story right (in Norm's
description you would have to tell the compiler to use the right file
name for the right option), they will perform the operation under
their authority.  This seems to further illustrate how the world is
not working based on capability system idioms.

> > Furthermore, just because capabilities do not have a direct analogy in
> > the real world does not mean that they are necessarily hard to
> > understand. 
> 
> To be fair, I don't think access lists have a direct analogy in the real
> world either; they are both idealized abstractions.

I concede.

Maybe both are approximately at the same level of abstraction.
Consider doors with locks and keys: That's the capability model.
Consider doors with names on them, and a magic force that stops people
who are not on the name list from entering (that magic force is of
course social norms).

> > So, maybe I am overemphasizing the issue of human nature.  But even
> > with all of the above in mind, I don't believe that a good
> > human-computer interface will reveal implementation details like
> > capabilities. 
> 
> I agree, with the caveat "except when necessary". Sometimes the only way
> to achieve a goal is the hard way.

If that is true, then it means that there is a good chance that the
goal won't be achieved at all, though.  Email is a prime example.
Everybody sends letters in a covert, but nobody encrypts email.  The
lack of widespread email encryption is a zillion times more
embarassing to the security community than the lack of capability
systems to the operating systems community.

Thanks,
Marcus