[cap-talk] Capability analogies

[Ka-Ping Yee]

On Wed, 3 Oct 2007, Matheus Morais wrote:
> I had based on 'What is a Capability, anyway?' essay write by shap but I
> didn't read the 'Capability Myths Demolished' fully yet. Right now I don't
> have any idea why keys aren't a good analogy to capabilities. I will read
> the paper to know more about this.

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.

People often use analogies to talk about programming ideas because
it's easier to think about concrete real-world actions and things than
abstract concepts.  Analogies are necessarily approximations; some
detail is lost in exchange for the understanding we hope to gain by
translating the ideas into more familiar terms.

It seems to me that the most common real-world analogies to ACL systems
consistently *overestimate* the security they are able to provide,
whereas the most common real-world analogies to capability systems
consistently *underestimate* the security they are able to provide.

I think this has been a significant factor in the persistent
misunderstanding of capability theory.

The typical real-world analogy for an ACL system is a bouncer.  You
show him your ID and he decides whether to let you in.  This analogy
errs in favour of ACLs:

  - It ignores the question of "Who issued the ID?" because people
    are in the habit of assuming that everyone has a driver license.

  - It ignores the question of "What makes the ID authentic?" because
    people are in the habit of assuming that everyone knows what a
    driver license looks like.

  - It ignores the question of "How do you know it's my ID?" because
    people have faces that can be photographed, but programs don't.

  - It ignores the difference between programs and processes.  In
    the real world it's not a normal use case to want to give birth
    to a child and grant him/her access to the club.  But programs
    instantiate other programs (or threads, or objects) all the time.

  - It's about protecting presence, not access.  The thing of value
    that the bouncer restricts is permission to *be* inside the club.
    To a person, there is a meaningful difference between experiencing
    a concert live and listening to a bootleg recording that a friend
    made at the concert.  But to a program there is no difference --
    information is information.

The typical real-world analogy for a capability system is a key.  If
you possess the right key, you can unlock the door and enter the room.
This analogy errs *against* capabilities:

  - It ignores confinement.  People are free to move about the world
    and interact with anyone.  So, naturally you can give anyone your
    key, or a copy of it.  Not true for programs.

  - It ignores delegation, to a degree.  It is usually obvious that
    keys are easier to delegate than IDs -- you can lend your friend
    a key.  But it is not usual for people to carry around key cutters
    and make duplicate keys instantly, whenever they want.

  - It ignores behaviour.  Keys are inert, but capabilities have
    programmable behaviour.  You can't give a key to a key.  That's
    nonsense.  But of course you can pass capabilities as arguments
    to other capabilities.

  - It ignores attenuation.  When people think about keys it doesn't
    occur to them that one could create keys on the fly that provide
    temporary access to the room -- or even to different parts of
    the room.  It is completely counterintuitive that one could do
    this without rekeying (reprogramming) the door, but just by
    programming the keys.

It seems to me that the natural tendency to analogize programs with
humans skews our perspective.  ACLs often work for humans.  Even so,
I still use the "key" analogy because keys have some advantages over
IDs.  Can we do better?


-- ?!ng