A capability is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object.
The term capability was introduced by Dennis and Van Horn [Dennis 1966]. The basic idea is that for a program to access an object, it must have a special token. This token designates an object and gives the program the authority to perform a specific set of actions (such as reading or writing) on that object. Such a token is known as a capability.
In an object-capability language, all program state is contained in objects that cannot be read or written without a reference, which serves as an unforgeable capability. All external resources are also represented as objects. Objects encapsulate their internal state, providing reference holders access only through prescribed interfaces [Mettler 2010A].
Every Java object has an unforgeable identity in addition to its contents, because the == operator tests reference equality. This unforgeable identity allows use of a reference to an object as a token, serving as an unforgeable proof of authorization to perform some action [Mettler 2010B].
Authority is embodied by object references, which serve as capabilities. Authority refers to any effects that running code can have other than to perform side-effect-free computations. Authority includes effects not only on external resources such as files and network sockets but also on mutable data structures that are shared with other parts of the program [Mettler 2010B].
References to objects whose methods can perform sensitive operations can serve as capabilities that enable the holder to perform those operations (or to request that the object perform those operations on behalf of the holder). Consequently, such references must themselves be treated as sensitive data and must not be leaked to untrusted code.
One surprising source of leaked capabilities and leaked data is inner classes, which have access to all the fields of their enclosing class. Java bytecodes lack built-in support for inner classes; consequently, inner classes are compiled into ordinary classes with stylized names, such as OuterClass$InnerClass. Because inner classes must be able to access the private fields of their enclosing class, the access control for those fields is changed to package access in the bytecode. Consequently, handcrafted bytecode can access these nominally private fields (see “Security Aspects in Java Bytecode Engineering†[Schoenefeld 04] for an example).
Rules regarding capabilities include:
2 Comments
Thomas Hawtin
An early update of 1.2 prevented classes with different signers from being loaded into the same package. So inner classes don't compromise signed code.
David Svoboda
Not sure I agree. I admit that the exploit from the old OBJ08-J didn't work if the untrusted code was in a separate package. But I suspect the theory posited here is still valid. Also the former OBJ09-J (AKA the new OBJ08-J) still demonstrates inner classes leaking sensitive data. (although they do it through more blatant means & don't require the clever but nonworking reflection exploit).