Capabilities

Capabilities[coslASdbl?>\ were introduced to overcome the limitations of segment based protection mechanisms. The major difference between a capability system and a segmentation system is that in a capability system, the access rights for a segment are

recorded with each copy of the segment's address[coh76,eng74,nee74,rey79,ros85]. This allows different instances of a segment's address to have different access rights. Thus, a segment used to represent executable code may appear to be modifiable to a compiler or appear executable to a calling program.

To complement the distribution of access rights, a capability system includes a protection mechanism to control the allocation and communication of capabilities. That is, a capability system includes a mechanism to prevent an erroneous program addressing or modifying a segment it should not have access to. For example, in the IBM System 38[rey79], a pair of storage words are used to represent a capability. Each word forming the capability is tagged. To prevent a capability being illegally modified, the tag bits are automatically reset whenever a word is modified. Hence, a capability that has been illegally modified will no longer be recognised as a capability.

Another protection mechanism applied to capabilities is to only allow them to occupy explicitly delimited areas of memory. For example, in Hydra[wul74], each segment may be composed of two areas, a data area and a capability area. The forgery of capabilities is prevented by only allowing capabilities to be moved between capability areas or between a capability area and one of the machine's capability registers. It is not possible to copy a section of a data area into a capability area. These rules, enforced by Hydra, ensure that a capability can only be created or modified via the system's protection mechanism and not by an erroneous program.

In addition to controlling the communication of a capability, it may be possible to modify the access rights of a capability. This may occur if a program wishes to release a reference to a private data structure without allowing other programs to modify that data structure. This can be achieved by allowing access rights to be removed from a capability whenever it is copied. Thus, the capability for the private data structure would have its update right removed fi:om the copies released by the program.

In general, it is undesirable to allow additional access rights to be added to a capability, since that would allow a program to invent access rights it was being denied. However, there is one case where it is necessary to add access rights, that is on a procedure call. In normal operation, a program will only have an execute right for the currently active procedure. For all other procedures, it will have a procedure call right, that is usually known as an enter capability. Thus, to be able to call a procedure and thereby execute it, the capability for that procedure must have the execute right added. This will be performed as one step when calling a procedure. A procedure call will also involve removing the execute

right from the capability for the calling procedure.

In a sophisticated capability system, it may be possible to define the environments in which a capability may be used. To understand why this is necessary, consider a database that permits a browser to access some of its data structures. In a simple capability system, the browser would be able to export the capabilities for any data it encountered, thereby allowing the database’s data to leak out. This would compromise any security the database was assumed to possess. To prevent such browser programs leaking information, some capability systems provide confinement or sealing/unsealing mechanisms, as outlined below.

The Hydra system supports confinement of capabilities[coh76] by providing access rights that allow a procedure to store a capability in an object other than its own activation record. Thus, the browser can be prevented from disclosing information by removing these additional rights from those capabilities the browser accesses. The capability system will then prevent the browser storing the capabilities in its own data structures or exporting them to other procedures.

The sealing/unsealing mechanism[wil82] works somewhat differently from the confinement mechanism. A sealed capability may be freely distributed throughout the system, but it

cannot be used until it is unsealed. The protection of the capability is achieved by controlling which procedures have access to the corresponding unsealing capability.

An alternative to the two previous protection mechanisms is to allow a capability to be revoked. That is, every copy of a capability, regardless of which access rights it may possess, is invalidated. This protection mechanism may be used to protect data by always handing out a capability that aliases the desired data. When the exported data has been used for its intended purpose, the alias capability can be revoked, thereby preventing any future misuse of the data.

It should be noted that in order to revoke a capability, it is necessary to be able to locate all copies of the capability. This ability can greatly complicate the design and implementation of a capability system. An example of a system that allows capabilities to be revoked is the Plessey System 250[eng74]. To avoid the additional complexity, systems such as Hydra support indirect addressing. A programmer may then make use of explicit indirections to simulate revoking a capability.

The type security mechanisms provided by segmentation and capability systems can be very sophisticated. However, they are all designed to be used with programs that may attempt to behave incorrectly. That is, the programs are able to directly manipulate their own data storage in an uncontrolled manner. These programs are not able to misinterpret segment addresses since these are explicitly protected by the capability system.

In some capability systems, the protection may be provided in part by software. To support this, the programs using the system may be required to conform to certain conventions. The enforcement of any conventions can never be assured if a program is written in assembly language. Thus, many capability systems do not allow assembly language to be used but rather enforce the use of one or more programming languages. For example, on the IBM System 38 programs are written in RPG-3[mye84]. Similarly, the MULTICS segmentation

system does not permit assembly language to be used, thereby preventing a program from accidentally altering segment addresses.