[cap-talk] Capability analogies

[Jed Donnelley]

On 10/4/2007 8:46 AM, Karp, Alan H wrote:
> Ping wrote:
>> I'll use this opportunity to mention a small insight that occurred to
>> me while discussing misconceptions about capabilities at this year's
>> Usenix Security.
>>
> Nothing small about that insight.
> 
> I use the key analogy, too.  Here are a couple of the stories I tell.
> They're both flawed, but they do seem to get the point across to people
> who've never thought much about access control.

I like your metaphors Alan (I've used the valet parking example
myself, though not with the ACL twist), but I'm not confident
such metaphors will help much in getting people to understand
capabilities.  In my experience (mostly with some 3k+ staff
members at LLNL using the capabilities in the Elephant Storage
system very successfully for some 25+ years) the capability concept
itself as a simple reference to an object (in that case only
directories and files) is simpler than any of the metaphors.

What I believe we need are examples of capability systems
with interfaces that can be demonstrated - e.g. like CapDesk
as MarcS demonstrates in:

http://video.google.com/videoplay?docid=-7961423532989255419#20m16s

> Confinement: 
> 
> Say that I need a copy of a key.  I walk into a hardware store.  Next to
> the key making machine I see a seedy looking fellow.  The "Born to Be
> Wild" tattoo and smell of funny cigarettes is a warning that this person
> may not be completely trustworthy.  What do I do?  Do I hand him my key
> and do some other shopping?  Of course not.  I stand there and watch to
> make sure that he doesn't make another copy and hand it to his partner
> in crime.  In other words, there is no authorization without
> communication.  Now, we can't always control who others communicate
> with.  However, when we can, this property gives us a powerful tool for
> understanding what can be done.

Yep.  In seems that in the computer case when we run the
program locally we can (in principle - e.g. on CapDesk)
control where the program can communicate.  It seems
pretty clear, however, that once we allow a program to
communicate to some remote entity we have to trust that
remote entity to limit any further communication/delegation.

> Attenuation (sort of)/Delegation:
> 
> Let's start with something we've all used, valet parking...

For me the highlight to your ACL example is:

> ...The attendant who has
> that authority left for the day and didn't have permission to update the
> car's access control list to delegate the necessary rights to someone
> else...

I think this points out what to me seems a rather fuzzy
aspect of ACLs.  Namely, who does have the authority to
update an ACL?  The typical answer is the "owner".  Who
is that?  Is that restricted to one ID?  In that case you
do get the problem you describe above.

If, however, this particular 'ownership' privilege of
being able to update the ACL is granted with every
permission to access the object, then ACLs can serve
much more like capabilities.  That is, they can support
a protocol that provides the ability to communicate
parameters that convey access to objects.  This is the
essence of the ACL method for communicating capabilities
described in:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

The "Reflection Problem" discussed there is an instance
of what Norm Hardy later called a Confused Deputy.

I believe if I was to update that paper to include
confinement then the issues would be similar to those
faced by the 'CapBrowser'.

--Jed  http://www.webstart.com/jed/