<< Previous <<         [Session1 Index]            >> Next >>

Capabilities and access control lists (ACLs) actually have a fairly symmetric relationship: in an access control list model of security, the authorities are bound to the objects being secured; in the capabilities model, the authorities are bound to objects seeking access. So if the objects are laid out in a table, with the access-seeking objects across the top and the security-seeking objects down the side, the columns represent sets of capabilities, and the rows represent individual access control lists.

Of course, this symmetry hides almost as much as it reveals, because such a table suggests that it doesn't make a difference which way you go: rows, columns, who cares?  As we have pointed out repeatedly here, it makes a very big difference, and you must care. For example, only by using columns (i.e., capabilities) can we solve the The Confused Deputy Problem.

A small distinction in the terminology hints at another crucial difference between ACLs and capabilities: with the ACL model, each object has just one list, while  with the Capability model, each object has a whole set of different , separable capabilities. Capabilities are fine-grained by nature; if the developer finds he doesn't have a facade on a capability that is quite as limited in authority as appropriate to maintain the Principle of Least Authority, it is generally trivial to whip up a new facade with an even narrower authority for the new purpose (though security-oriented design will lead you to identify and separate out individual capabilities early on).

This fine-grained nature of capabilities becomes more apparent as you use them more, and evolve in the Path Of Security Thinking.