Capability Security Model
Capability Security Model'CapabilitySecurityModel' describes a broad spectrum of SecurityModels that attach service-authorizations to the entities demanding the service. These service-authorizations are appropriately termed 'capabilities'. This is in opposition to attaching service authorizations to the entity providing the service; for example, an AccessControlList that is attached to a directory and indicates 'who' may enter/read/write/etc. does not qualify as a capability.
The practical advantages of a CapabilitySecurityModel over its alternative (the main competitor being AccessControlLists) stem from the fact that changing AccessControlLists is, in practice, a very difficult social and political problem: there is rarely a clear indicator of exactly whom should have authority (the capability) to change it, which means it gets delegated to some 'Trusted Computing Base' (e.g. the root hacker), and all change requests end up being bottlenecked through some individual who's had a long day and is nursing a headache. Capabilities, in comparison, offer a great deal more flexibility and reduce maintenance costs: if you have a capability, you can copy it to someone else, so they have the capability too, and it would be very much like you were doing whatever it is they want to do on their behalf... except that you can go home and watch Simpsons while your trusted friend, Fred, does whatever he wanted to do. It has been proven that CapabilitySecurityModel and AccessControlLists technically offer the same theoretical granularity when it comes to controlling service access (since they both expand to the same sparse matrix with entities on one axis and services to resources on another), but it is unlikely that it will ever be realized.
That said, the AccessControlList approach does offer some advantages. First, in reality, trust is NOT transitive... i.e. if I trust you, and you trust Fred, it doesn't mean that I trust Fred, or that I'd let Fred into my house where he can drink my beer. And if I loaned you my lawnmower, it doesn't mean I'm permitting you to loan it out to everyone else - especially given that I could be liable if some child were hurt. AccessControlList allow for direct expression and enforcing non-transitive trust, whereas capabilities do not. However, it can be reasonably argued that AccessControlList is promising something impossible: that if you have access to a resource, you can always copy that resource and show it to Fred... or you can even give Fred all the information he needs to masquerade as you and confuse me (e.g. give Fred your passwords, supposing the authenticity tests don't involve study of habit-patterns and biometrics), or you can allow Fred to use you by relaying requests through you. These are all possible. Thus, some people have noted that despite trust not being transitive, attempting to enforce non-transitive trust is difficult or impossible in the face of treachery. So, perhaps, what ACLs offer isn't protection against intentional treachery, but rather protection against treachery of the more accidental sort, and a certain degree of social pressure to avoid mistake (e.g. if giving away a particular capability requires giving away both your CommonAccessCard? and Password which has access to your e-money, most people can be taught and comprehend that this is a bad thing; if it also requires giving one of your eyeballs for an iris scan challenge by the CAC, then most people would be quite resistant to ever trying.)
There actually have been attempts to unify these. The HybridCapabilityModel simply glues both together (you must satisfy ACL and Capability), which neatly gains you both some of the best and some of the very worst of both worlds. SplitCapabilityModel is even worse, requiring the same 'trusted computing block' table as the original ACLs plus requiring that every capability call back into this TCB. SPKI and certificates, however, do offer a fairly simple approach: allow capabilities to be tied to a particular user by requiring they sign with a private key each use of the capability with a time (or any uniquely scoped session identifier verifiable by the capability enforcer - e.g. a transaction ID from a shared transaction manager - to prevent replay attacks). So long as these entities can keep their private key private (which for process-objects only requires trusting the hosts upon which they are running... which does limit mobility a bit) one has the potential to create capabilities that are scoped to exactly one entity... i.e. the equivalent to ACL-granted authority.
How about some specific realistic scenarios that show the alleged drawbacks of ACL's. The accusations against it here are not specific enough to dissect, analyze, and confirm.
Do you have a specific question? Your claim against the accusations is not specific enough to answer.
'The original' ObjectCapabilityModel:
A security model (CategorySecurityModel) in which all resources are referenced by "capabilities" that both designate the resource, and authorize access to it. The mechanism by which resources are created ensures that 'names' cannot easily be guessed and are thus 'unforgeable'. Possessing a reference to an object is considered a sufficient indicator of the right to act upon that reference. It is assumed that if you pass a reference to another object, you're giving them full permission to do anything that object is willing to do. Security is enforced by creating 'new' objects that limit the actions (e.g. by throwing exceptions or returning without operation) when the caller attempts a blocked action. It is assumed that you can trust the ObjectSystem environment and host computer to not intentionally violate the security system.
This is 'the original' capability security model as described by DennisAndVanHorn. However, the term "capability security" has since been used rather imprecisely, sometimes to describe security models that have little to do with the DennisAndVanHorn model. The new name ObjectCapabilityModel has been proposed by some researchers (see ParadigmRegained) in an attempt to reduce this confusion.
Some of the other models that have come to be known as "capability" models are
Is the WikiPedia "Capability based security" at http://en.wikipedia.org/wiki/Capability-based_security talking about the same subject?
Discussion moved into CapabilitySecurityDiscussion.
For differences between capability and OO programming, see CapabilityOrientedProgramming.
See RightsAmplification, which discusses couple variations on a useful pattern oft found in CapabilitySecurityModels.
See also CapabilityUserInterface AntiCapQuotes.
EditText of this page
(last edited April 9, 2010)
or FindPage with title or text search