Security in a Secure Capability-Based System

Charles R. Landau
Scientist

Key Logic
5200 Great America Parkway
Santa Clara, California 95054-1108

This note originally appeared in Operating Systems Review, October 1989.

Abstract

Capability-based systems such as KeyKOS support mandatory and discretionary security policies without identifying the source of every request. Some misconceptions about such systems are clarified.

Introduction

Gong, in a recent paper [Gong], argues with Hogan [Hogan] that to enforce security, the source of every request must be identified. The only exception is "at most one special type of capability system" in which "the manipulation of capabilities must be done by trusted hardware." Gong goes on to say that such systems are "not suitable to the open system architecture" and are complex, difficult, costly, and unable to network. These conclusions are unwarranted by the facts.

Gong's discussion introduces, without definition, the term "fully armed system." In this paper we use the KeyKOS^® system [Hardy] with KeySAFE [KeySAFE] as an example of a system that need not identify the source of every request. We thereby circumvent a debate about the meaning of the term "fully armed system." Gong is however partially correct. The truth is that the source of some requests must be identified.

KeySAFE is the name given to the security specific programs that use KeyKOS as a base. KeySAFE is designed to meet both the discretionary and mandatory security policies at the B3 level as described in the "orange book" [DOD]. It should be emphasized that the KeyKOS platform has the flexibility to support a variety of security policies. We are using KeySAFE and orange book policies as an example to show that capability-based systems can support meaningful security policies.

Previous papers [Wells, Rajunas] have hinted at the design of KeySAFE. [KeySAFE] describes it in detail. Because that information has not received wide distribution, and because confusion still appears to exist about security in capability based systems, we summarize here the design of KeySAFE.

KeySAFE

KeySAFE defines a compartment for each subject. (This term has been used with a slightly different meaning elsewhere in the security literature. It is used here to emphasize that each subject is compartmentalized, i.e. separate from other subjects.) All capabilities in a compartment are either to other objects within the same compartment, or are mediated by a trusted reference monitor. Similarly, all capabilities outside a compartment are either to objects outside the compartment or are mediated by the reference monitor.

By "mediated" we mean that the capability is under the control of the reference monitor to an extent that allows the reference monitor to enforce its security rules. An indirection mechanism allows access to be rescinded by the reference monitor at any time. It also allows the reference monitor to enforce read only access, and to prohibit the passing or receiving of other capabilities.

It is easy to show that no subject within a compartment can gain access to any object outside the compartment except through the reference monitor. (In the terminology of [Snyder], the compartments are not tg -connected except through the reference monitor.)

Usually a compartment will contain the tools required by the subject to do his/her job, such as command interpreters, editors, and other useful facilities. (Actually it contains read-only capabilities to the code of the tools; the code can be shared between all compartments as long as it is system low.) As long as a subject accesses objects within its own compartment, no special access checking, other than that implied by the term capability-based, is needed. In particular the source of the request need not be identified -- we just know it is from somewhere within the same compartment.

Initially, the only capability leading out of the compartment is the guard capability, which leads directly to the reference monitor. This capability allows the subject in a compartment to create objects with security labels, specify their access control lists, and have them made available to other compartments through the reference monitor (subject to mandatory and discretionary access control). The guard is also the means by which subjects obtain capabilities to such objects created by other compartments. Each compartment has its own unique guard, which allows the reference monitor to identify the compartment which made the request.

Capabilities are never transferred directly from one compartment to another. Instead, a new capability, mediated by the reference monitor, is given to the requesting compartment.

The National Computer Security Center's Commercial Products Evaluation Division conducted an analysis of capability-based systems and concluded that such systems can be developed which satisfy the upper level requirements of the "orange book." The NCSC began evaluating KeyKOS and KeySAFE for a high B-level rating in May 1988.

Clarifications

Some of Gong's conclusions may stem from the misunderstanding that "a capability is a string of bits." Although at some level a capability is implemented by such details as bits and electrons, the user never sees these. The representation of a capability in KeyKOS is as invisible to the user as the representation of the bits of the machine registers in semiconductors. A user cannot forge a capability out of bits, nor can capabilities be leaked through data networks.

KeyKOS does not use special-purpose capability hardware. KeyKOS has a trusted software kernel. The use of microcode to implement computer system features blurs the line between hardware and software. Features such as capabilities can be successfully implemented in hardware, microcode, or kernel software. KeyKOS performance has been demonstrated to be very competitive in commercial applications [KeyTXF].

Object-oriented systems make an ideal platform for open systems, because they allow the definition of new object types. The capability model is well suited to the implementation of such systems. Capability based object-oriented systems also allow the definition of new security policies without altering the basic security mechanism. In a network environment, the reference monitor can implement a range of policies for dealing with requests from the network.

Summary

In summary, when a capability propagates between compartments, security policy and identities must be checked. Within a compartment, capabilities can be freely used and propagated with no checking of the source, resulting in high efficiency without loss of security.

References