As an abstraction, capability-based systems have long had a devoted following. The idea that all access to objects by programs is mediated by hardware, and only explicitly allowed access succeeds, is very seductive to computer scientists seeking a world without--or with fewer--biting bugs in programs.

Refining the abstraction in the attempt to reach real, implementable systems has proceeded slowly. A particular problem is the management of the capabilities themselves--what operations are allowed on capabilities, and what are the implications of those operations on control of access to the objects to which the capabilities are . . . capabilities?

A second concern of this paper is the ability of capability-based systems to satisfy DoD (Department of Defense) mandatory and discretionary security policies, in particular the “*-property.” Annoyingly, this paper does not define the *-property explicitly but suggests that it means that a process can read data only at its own or a lower security level, and can write data only at its own or a higher security level.

The authors review current opinion that relates capability-based systems and the DoD requirements. They then present their own taxonomy for evaluating the protection mechanisms provided by various system designs. Finally, they propose two designs, described through their taxonomy, that can enforce the *-property. It appears that the addition to the “basic” capability-based system that allows their designs to satisfy the DoD requirements is the notion that capabilities stored within a segment carry their own security level, which is not necessarily the same level as that of data stored within the same segment.