Dennis, Van Horn, and Capability Security: Authority as an Unforgeable Reference
Jack Dennis and Earl Van Horn helped establish the capability idea: access could be represented by protected references that combine object identity with authority, making permission a property of what a program possesses rather than a global name lookup.
Protection became a naming problem as computers began sharing resources
Early multiprogramming systems forced a new question: when several programs share a machine, how should one program refer to a resource without automatically gaining authority over every resource it can name? Jack B. Dennis and Earl C. Van Horn’s 1966 paper on programming semantics addressed this problem by defining protected operations for sharing memory segments and other computing objects among concurrent computations.[1]
The historical importance of that work is not that it invented every later capability mechanism in finished form. It is that it helped make authority explicit in the reference itself. A protected reference could identify an object while simultaneously limiting which operations the holder was permitted to perform.
A capability binds an object reference to access rights
In a capability system, possession of a valid capability is evidence that a subject may perform some operation on the referenced object. Modern capability systems often describe the idea as a protected or unforgeable token containing both an object reference and rights.[5]
This differs from a conventional global-name model in which a process presents a filename or identifier and the system separately consults an access-control list. Capabilities move part of the authorization decision into the structure of the reference.
Authority travels through controlled delegation
If one component legitimately possesses a capability, it may be able to pass a restricted capability to another component. Delegation therefore becomes an explicit system operation rather than an informal side effect of sharing a name.
Dennis and Van Horn treated protected sharing as a programming semantic
The 1966 paper described meta-instructions for creating and coordinating computations, protecting separate computations, debugging programs, and sharing hierarchically named objects.[1] The authors were trying to define programming concepts suitable for multiprogrammed systems rather than merely documenting one machine’s protection registers.
That framing mattered. Protection was becoming part of the programming model itself. Programs needed a disciplined way to create objects, refer to them, share them, and limit what another computation could do with them.
A reference could be more than an address
An ordinary memory address says where something is. A capability can say both what object is meant and what authority is conveyed. That fusion became a recurring design pattern in secure operating systems.
Lampson’s access matrix clarified the broader design space
Butler Lampson’s influential protection model described systems in terms of subjects, objects, domains and permitted operations, giving researchers an abstract vocabulary for comparing mechanisms such as access lists and capabilities.[2]
The access matrix perspective showed that the same conceptual rights relation can be represented in different ways. An access-control list is naturally organized around an object and the subjects permitted to use it; a capability list is naturally organized around a subject or protection domain and the objects it may use.
The representation changes the economics of delegation
When authority is represented by capabilities, granting access can look like handing over a protected reference. This can make fine-grained delegation natural, but it also creates engineering questions about revocation, confinement, persistence and safe transfer.
Saltzer and Schroeder placed capabilities inside a general theory of protection
Jerome Saltzer and Michael Schroeder’s 1975 survey examined capability systems alongside access-control-list systems and protected subsystems.[3] Their treatment helped connect capabilities to enduring security principles such as least privilege, complete mediation and economy of mechanism.
Least privilege is especially compatible with capability thinking: a component should receive only the references it needs, with only the rights required for its task. Authority can therefore be constructed as a narrow set of capabilities rather than inherited from a broad ambient identity.
Capability systems survived repeated claims that they were impractical
One recurring criticism was performance. Fine-grained protected references, checking, persistence and delegation appeared likely to impose significant overhead compared with conventional process and file models. The EROS system revisited that assumption on commodity hardware and reported that a carefully designed capability microkernel could achieve competitive basic-operation costs.[4]
EROS also connected the capability lineage to earlier systems such as GNOSIS and KeyKOS, showing that capabilities were not merely a theoretical alternative but a continuing operating-system architecture.
Capabilities do not automatically solve every security problem
Capabilities constrain authority, but designers must still handle revocation, availability, side channels, covert channels, buggy trusted components and policy mistakes. The model narrows what a component can directly do; it does not make software infallible.
Modern verified kernels keep the capability concept alive
The seL4 microkernel uses capabilities as the fundamental mechanism for controlling access to kernel objects. Its documentation describes a capability as a unique, unforgeable token that identifies an object and conveys specific rights; kernel operations are authorized by invoking such capabilities.[5]
This modern implementation makes the historical continuity visible. The machinery is far more sophisticated than the semantics proposed in the 1960s, but the core question remains recognizable: how can software components be given exactly the authority they need, in a form the system can reliably enforce?
Why capability security belongs in the history of trust
Capability systems offered a different answer to access control from the familiar account-and-permission model. Rather than asking only who a process is, they ask what protected references it actually possesses and what rights those references convey.
Dennis and Van Horn belong in this history because their 1966 work helped formulate protected object references as part of the semantics of multiprogramming.[1] Lampson, Saltzer and Schroeder generalized the design space, later systems demonstrated practicality, and seL4 shows that the capability idea remains a live foundation for high-assurance computing.[2][3][4][5]
Works Cited
- 01
- 02
- 03
- 04
- 05seL4 Documentation — Capabilities Tutorial docs.sel4.systems
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead