Capability-based security

Missing image Merge_articles.png

It has been proposed that this article or section be merged with Capability (computers). This request may be discussed on the article's talk page.

Capability-based security is a concept in the design of secure computing systems. It refers to the principle of designing user programs such that they directly share capabilities with each other according to the principle of least authority, and the operating system infrastructure necessary to make such transactions efficient and secure.

An alternative to capability-based security that is used in most commercial operating systems is that of access control list-based security, in which a process gains access to objects by presenting an unprivileged reference to the operating system, to which the system responds by determining which access rights are appropriate for that object based on the requesting process's user identity. In a capability-based system, user programs deal not with unprivileged references but privileged capabilities. Because the capabilities are already known to be legitimate ways to access the object, there is no need for an access validation step based on user identity or other factors.

Although most operating systems implement a facility which resembles capabilities, they typically do not provide enough support to allow for the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system. A capability-based system, in contrast, is designed with that goal in mind.

Introduction to capability-based security

(The following introduction assumes some basic knowledge of Unix systems.)

A capability is defined to be an object which, by virtue of its possession by a user process, grants that process the capability (hence the name) to interact with an object in certain ways. Those ways might include reading data associated with an object, modifying the object, executing the data in the object as a process, and other conceivable access rights. The capability logically consists of a reference that uniquely identifies a particular object and a set of one or more of these rights.

Suppose that, in a user process's memory space, there exists the following string:

    /etc/passwd

Although this uniquely identifies an object on the system, it does not specify access rights and hence is not a capability. Suppose there is instead the following two values:

    /etc/passwd
    O_RDWR

This identifies an object along with a set of access rights. It, however, is still not a capability because the user process's possession of these values says nothing about whether that access would actually be legitimate.

Now suppose that the user program successfully executes the following statement:

    int fd = open("/etc/passwd", O_RDWR);

The variable fd now contains the index of a file descriptor in the process's file descriptor table. This file descriptor is a capability. Its existence in the process's file descriptor table is sufficient to know that the process does indeed have legitimate access to the object. Note that a key feature of this arrangement is that the file descriptor table is in kernel memory and cannot be directly manipulated by the user program. The operating system must ensure that only specific operations can occur to the capabilities in the system, in order to maintain the integrity of the security policy.

In traditional operating systems, programs often communicate with each other and with storage using references like those in the first two examples. Path names are often passed as command-line parameters, sent via sockets, and stored on disk. These references are not capabilities, and must be validated before they can be used. In these systems, a central question is "on whose authority is a given reference to be evaluated?" This becomes a critical issue especially for processes which must act on behalf of two different authority-bearing entities. They become susceptible to a programming error known as the Confused deputy problem, very frequently resulting in a security hole.

In a capability-based system, the capabilities themselves are passed between processes and storage using a mechanism that is known by the operating system to maintain the integrity of those capabilities.

Research and commercial systems

• EROS
  • KeyKOS - EROS's predecessor
• Cambridge CAP computer
• CMU C.mmp with Hydra operating system
• CMU CM* with StarOS
• IBM System/38 and AS/400
• Intel iAPX 432
• Plessey System 250