[cap-talk] Capability analogies

[Karp, Alan H]

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.

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.

Attenuation (sort of)/Delegation:

Let's start with something we've all used, valet parking.  OK.  I'm a
tightwad.  I never use it, but you're more reasonable about such things,
aren't you?  It's relatively easy to do.  You stop at the kiosk, get a
receipt, and give the attendant the valet key to your car.  That key
works in the door lock and the ignition but doesn't open either the
trunk or glove compartment.  The valet key is a good example of POLA.
It's also a good example of an authorization, one that denotes
permission to unlock the door and start the engine.

When you want to retrieve your car, you present your claim check to any
attendant.  That attendant then unlocks the key storage cabinet,
retrieves your key, runs off to the locked parking area, and delivers
your car to you.  At no time does anyone associated with the parking
service have the authority to open your car's trunk or glove
compartment.

Now let's travel to a parallel universe where valet parking is handled
the way access to resources is controlled on our computers.  You pull up
to the kiosk, get a receipt for your car, and ask the attendant for
identification.  You create an entry in your car's access control list
that grants the attendant permission to unlock the door and start the
car.  Not granting the attendant access to the trunk or glove
compartment is a good example of POLA.  When you want to retrieve your
car, you present your claim check to the same attendant, who retrieves
your car for you.

Things get interesting when that attendant is not available.  No other
attendant has the authority to drive your car.  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.  You don't have access to your car to authorize another driver
because you're not on the guard's list of people authorized to enter the
locked parking area.  Don't worry, though.  When the manager comes in
tomorrow, he'll straighten things out.

Of course, the problem of the missing attendant is easily solved.
Instead of granting access to a specific attendant, you create an entry
in your car's access control list for the role of valet parking
attendant.  Now, any of the attendants can retrieve your car.  Of
course, there must be some way for your car to correctly identify
someone in the role of valet parking attendant.  That means you must add
a procedure to your car's authentication system that recognizes whatever
this particular valet service uses as certification that someone is a
valet parking attendant.  Hmmm.  Maybe it'll be easier to wait for the
manager.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp