Object-capability model

The object-capability model is a computer security model. A capability describes a transferable right to perform one (or more) operations on a given object. It can be obtained by the following combination:

• an unforgeable reference (in the sense of object references or protected pointers) that can be sent in messages.
• a message that specifies the operation to be performed.

The security model relies on not being able to forge references.

• Objects can interact only by sending messages on references.
• A reference can be obtained by:

1. initial conditions: In the initial state of the computational world being described, object A may already have a reference to object B.
2. parenthood: If A creates B, at that moment A obtains the only reference to the newly created B.
3. endowment: If A creates B, B is born with that subset of A's references with which A chose to endow it.
4. introduction: If A has references to both B and C, A can send to B a message containing a reference to C. B can retain that reference for subsequent use.

In the Object-capability model, all computation is performed following the above rules.

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. ^{[1] [2]}

The object-capability model was first proposed by Jack Dennis and Earl C. Van Horn in 1966.^[3]

Loopholes in Object-Oriented Programming Languages

Some object-based programming languages (e.g. JavaScript, Java, and C#) provide ways to access resources in other ways than according to the rules above including the following:

• global variables exported into the environment in JavaScript
• static methods in Java and C#
• direct assignment to the instance variables of an object in Java and C#
• direct reflexive inspection of the meta-data of an object in Java and C#
• the pervasive ability to import primitive modules, e.g. java.io.File that enable external effects.

Such use of undeniable authority effectively defeats the security benefits of the Object-capability model. Caja and Joe-E are variants of JavaScript and Java, respectively, that impose restrictions to eliminate these loopholes.

Advantages of object capabilities

The structural properties of object capability systems favor modularity in code design and ensure reliable encapsulation in code implementation.

These structural properties facilitate the analysis of some security properties of an object-capability program or operating system. Some of these — in particular, information flow properties — can be analyzed at the level of object references and connectivity, independent of any knowledge or analysis of the code that determines the behavior of the objects. As a consequence, these security properties can be established and maintained in the presence of new objects that contain unknown and possibly malicious code.

These structural properties stem from the two rules governing access to existing objects:

1) An object A can send a message to B only if object A holds a reference to B.

2) An object A can obtain a reference to C only if object A receives a message containing a reference to C.

As a consequence of these two rules, an object can obtain a reference to another object only through a preexisting chain of references. In short, "Only connectivity begets connectivity."

Glossary of related terms

object-capability system

A computational system that implements principles described in this article.

object

An object has local state and behavior. An object in this sense is both a subject and an object in the sense used in the access control literature.

reference

An unforgeable communications channel (protected pointer, opaque address) that unambiguously designates a single object, and provides permission to send messages to that object.

message

What is sent on a reference. Depending on the system, messages may or may not themselves be first-class objects.

request

An operation in which a message is sent on a reference. When the message is received, the receiver will have access to any references included in the message.

attenuation

A common design pattern in object-capability systems: given one reference of an object, create another reference for a proxy object with certain security restrictions, such as only permitting read-only access or allowing revocation. The proxy object performs security checks on messages that it receives and passes on any that are allowed. Deep attenuation refers to the case where the same attenuation is applied transitively to any objects obtained via the original attenuated object, typically by use of a "membrane".

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, Integrity (operating system), CapROS, Coyotos, seL4, OKL4 and Fiasco.OC are secure operating systems that implement the object-capability model.

Languages that implement object capabilities

• Act 1 (1981) ^[4][5]
• 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 — present)
• Jacaranda (2008-9)

Relationship of the Object-capability model and the Actor model

Most of the object-capability model was first formalized as the Actor model of concurrent computation as follows:.^[6] However, there are a few differences between the object-capability model and the Actor model:

• Since object-capability systems differ regarding concurrency control, storage management, equality, typing, the primitiveness of messages, and the ordering of message delivery, the object-capability model by itself is neutral on these issues. By contrast, the Actor model does specify some of these elements. In this sense, the Object-capability model corresponds most directly to the Actor locality laws taken by themselves. In particular there are the following differences:

• concurrency control
• storage management
• equality
• typing
• primitiveness of messages
• ordering of message delivery

• The object-capability model requires a loader (eval, exec) having the property of "loader isolation". A loader loads data describing behavior (code, script, lambda expression) together with an initial state (c-list, environment, instance variable frame, acquaintances) to create a new object. A loader obeys loader isolation if the new object's only initial references are from the explicitly provided state, with no implicit grants by the loader itself. On the other hand, the Actor model simply requires that loaders, evaluators, etc. obey the laws for actors. The Java ClassLoader violates loader isolation, making confinement of unexamined loaded code impossible.
• There are minor differences in the preferred terminology used for the two models (see "Glossary of related terms" above).

Of course, some systems have all the properties required by both models, and so are both Object-capability systems and Actor systems.

See also

• Capability-based security
• Capability-based addressing
• Actor model

References