For capability-based protection mechanisms a useful physical analogy is that each object is contained within a house having several doors that open into different rooms, and capabilities are keys to these doors. The object field in a capability is analogous to a pattern of notches on the key, and the access rights are a set of auxiliary `bumps' that permit access to particular doors of the house. When a house (object) is constructed, the system gives the creating person (process) a key (capability) that will open all doors in the new house. What transpires after this is up to the person using the initial key.
To make this world of locks and keys a secure and useful one, one arrives at the following considerations:
It must be impossible for a person to fabricate a key. Also, given a key, it must be impossible to alter the notches to open a different house or a different door.
Given a key, it should be possible to make a copy of the key, either for oneself or for someone else.
Given a key, it should be possible to remove (but not add) one or more of the auxiliary bumps to remove some of the key's access rights.
For generality, one should be able to move and store keys in the same way as any other entity.
This analogy introduces some problems that need to be addressed by
capability-based systems:
The `do not copy' problem
In the locked-house world, person A might wish to give person B a key to a door in a house, but might want to preclude B from copying the key, for instance, to give it to a third party. Hence, one needs a mechanism to stamp a `do not copy' on a key.
This can be achieved in capability-based system by associating each
capability with capability rights in addition to the other
rights.
One of these rights determines if the capability can be copied.
The retraction problem
It is often important to be able to withdraw authority after it has been given. For instance, one might have given 10 people keys to a door, and then later decide that person D should no longer have have a key.
One solution is indirection: Rather than handing out keys to the house itself, one might hand out keys to a second house that contains a key to the first house. Hence one can withdraw the authority of a particular person or a class people by destroying one of the secondary `key-holding' houses.
Thus capability-based systems often support indirect capabilities
that,
from the holders point of view,
can be used as direct capabilities.
However,
the creator of such a capability can invalidate the capability
by destroying the intermediate object.
The `what is this key' problem
The closest physical analogy to this problem is
having no information about the properties of a key on a key chain.
It represents a set of situation where the operating system
has useful information that is not available to programs.
Therefore some systems provide a describe-capability operation that
given a capability,
returns its type and
access rights but not the internal representation of the object.