Object-capability model
From Wikipedia, the free encyclopedia
 |
It has been suggested that this article or section be merged with Capability-based security. (Discuss) |
The object-capability model is a computer security model based on an object-oriented model of computation. The name "object-capability model" is due to the idea that idealized object-based programming and capability-based programming are two ways of looking at the same thing. Under the object-capability paradigm:
- Objects are both accessed and designated through unforgeable references called capabilities.
- Objects interact by sending messages along these capabilities.
- A capability can be obtained by:
- initial conditions (the system starts up with a set of objects that may have capabilities to each other)
- parenthood (the creator of an object has a capability to the created object)
- receiving a message (objects can embed capabilities in the messages they send)
In a pure object-capability system, all computation is performed by objects that follow these rules: The only way an object can affect the world outside itself is by sending messages on references it holds to other objects. Therefore, we can control an object's authority to cause effects by controlling what references it may come to hold.
In "pure" object-oriented programming (where everything is an object and all computation is method invocation), references to objects can be treated as capabilities in the sense of capability-based security — since they are, in fact, unforgeable references that can be passed in messages to other objects. Advantages that motivate object-oriented programming, such as encapsulation or information hiding, modularity, and separation of concerns, correspond to security goals such as least privilege and privilege separation in capability-based programming.
Not all object-based programming languages and systems are implementations of the object-capability model. An object-based system may provide access to resources in other ways than according to the rules above, for example, via global variables or static methods. Such use of ambient authority effectively defeats the security benefits of a pure object model.
Contents |
[edit] Advantages of object capabilities
In an object-capability system, existing objects can only obtain new capabilities to other existing objects through messages. Also, a capability to an object is required in order to send a message to that object. Taken together, these two things mean that two objects can only get access to each other if they are already connected through some chain of capabilities, or, in short, "only connectivity begets connectivity."
A correctly built object-capability program is naturally modular. Key security properties of an object-capability program or operating system can be analyzed. Some of these properties — in particular information flow properties — can be analyzed without knowing anything about what code the programs run.
[edit] Glossary of related terms
- object-capability system
- A computational system that implements abstractions consistent with the other definitions below.
- object
- A computational resource that may have state and behavior. An object in this sense is both a subject and an object in the sense used in the access control literature. Object-capability systems may differ in respects such as whether objects are active processes.
- reference
- An unforgeable identifier that unambiguously designates a single object and grants permission to invoke it.
- capability
- A reference to a non-data object.
- invocation
- An operation in which a message is sent to a target object via a capability. After an invocation, the target object will have access to any capabilities and data included in the message.
- message
- What is sent in an invocation. Depending on the system, messages may or may not themselves be first-class objects.
- reply (or response)
- A common pattern of interaction is that one object (Alice) invokes another (Bob), and then Bob sends a reply back to Alice. In the object-capability model this is considered as two invocations (even if a particular system combines sending a message and waiting for a reply into a single primitive operation).
- permission
- The ability to directly perform some primitive operation. In object-capability systems, possession of a capability to an object grants permission to invoke it.
- authority
- The ability to cause some effect, directly or indirectly.
- composite, facet
- A composite is an abstraction that may consist of several cooperating objects. Some of these objects may be accessed from outside the composite, and are called facets of the composite. It may be possible to describe a system as being constructed from composites in several different ways, depending on the level of abstraction desired.
- attenuation
- A common design pattern in capability systems is, given one capability, to create another that designates the same composite but with certain security restrictions, such as only permitting read-only access or allowing revocation. In the case of "deep attenuation", the restriction also applies transitively to any objects referenced from the attenuated capability (for example, read-only access to all of the files and directories below a given point in a directory tree).
[edit] Implementations
Almost all historical systems that have been described as "capability systems" can be modeled as object-capability systems. (Note, however, that some uses of the term "capability" are not consistent with the model, such as POSIX "capabilities".)
KeyKOS, EROS, CapROS, and Coyotos are secure operating systems that implement the object-capability model.
[edit] Languages that implement object capabilities [1]
- Actors (1973),
- Eden (1985),
- Vulcan (1986),
- Emerald (1987),
- Trusty Scheme (1992),
- W7 (1995),
- Joule (1996),
- Original-E (1997),
- E (1998),
- J-Kernel (1999),
- Oz-E (2005),
- Joe-E (2005),
- CaPerl (2006),
- Emily (2006)
- Caja (2007)
[edit] See also
[edit] References
Mark S. Miller, Jonathan S. Shapiro (December 2003). "Paradigm Regained: Abstraction Mechanisms for Access Control". Proceedings of ASIAN'03, Springer-Verlag.
Mark S. Miller, Ka-Ping Yee, Jonathan S. Shapiro (2003). "Capability Myths Demolished" (PDF). Technical Report SRL2003-02. . Systems Research Lab, Johns Hopkins University
