Capability Myths Demolished

Reference

Miller, Mark S.; Yee, Ka-Ping; Shapiro, Jonathan S. Capability Myths Demolished. Technical Report SRL-2003-02, Systems Research Laboratory, Johns Hopkins University, 2003. URL

Summary

This short, polemical technical report dismantles three widely repeated myths about capability-based security that had accreted in the literature over the preceding two decades and were being cited as reasons to avoid capability models or to pile extra access checks on top of them. The three myths are: (1) the Equivalence Myth - that ACL systems and capability systems are formally equivalent views of Lampson’s access matrix; (2) the Confinement Myth - that capability systems cannot enforce confinement; and (3) the Irrevocability Myth - that capability-based authority cannot be revoked.

The authors’ strategy is to disentangle three very different things all called “capability” in the literature: Model 2 (capabilities-as-rows of the access matrix), Model 3 (capabilities-as-keys / unforgeable bitstrings), and Model 4 (object-capabilities, where capabilities are object references in a memory-safe object language). They define seven security properties - including “no designation without authority,” dynamic subject creation, subject-aggregated authority management, and composable confinement - and show how the three models differ on each. Under this lens, the Equivalence Myth collapses: ACLs and object-capabilities have fundamentally different rules for how the access matrix is updated, even if both can be drawn as an access matrix at an instant.

The Confinement Myth is refuted by pointing to KeyKOS factories (Hardy 1988) and the EROS constructor, which demonstrably achieve confinement in object-capability systems. The Irrevocability Myth is refuted via the Redell forwarder/facet pattern (1974), elegantly explained with a simple diagram: Alice hands Bob a forwarder to Carol and keeps the revoker; dropping the revoker drops Bob’s access. The paper is the go-to reference whenever these myths resurface and is essential intellectual groundwork for the ocap tradition.

Key Ideas

Three distinct capability models: capabilities-as-rows, capabilities-as-keys, object-capabilities - not interchangeable.
The access-matrix snapshot lies: static snapshots ignore the update rules that actually distinguish ACL systems from capability systems.
No Designation Without Authority (Property A): in an ocap system, to name a resource is already to have authority to use it; ACL systems decouple designation from authority, which is the root of confused-deputy problems.
Subject-Aggregated Authority Management (Property C): in ocap, you edit your own C-list; in ACLs, changing one authority requires editing a resource’s ACL.
Confinement is achievable via factories / constructors; KeyKOS and EROS are existence proofs.
Revocation by forwarders (facets): give Bob not Carol but a forwarder F; keep R as revoker; R !stopForwarding revokes Bob cleanly.
Object capabilities subsume Lampson while avoiding the ambient-authority pitfalls that produce confused deputies.

Connections

The Heart of Spritely - Distributed Objects and Capability Security
Capability Security - this paper is the canonical clarification of what capability security actually claims.
Object Capability Security - Model 4 in this paper is the object-capability model.
E Language - examples and diagrams use E-flavoured ocap reasoning.
CapTP - distributed ocap relies on the same non-myths.
Ambient Authority - the Equivalence Myth’s error is essentially failing to see ambient authority in ACL systems.
Confused Deputy - the paper leans on Hardy’s example to justify Property A.
Principle of Least Authority - POLA is called out as a motivation for preferring ocap.
Distributed Security
Security Kernel Lambda Calculus
Capability Revocation - Redell forwarders / facets are explained here.
Capability Bounding

Conceptual Contribution

Most criticisms of capability-based security dissolve once one distinguishes three very different things the word “capability” has named. Object-capabilities (references in a memory-safe object language governed by reference-passing rules) are neither equivalent to ACLs, nor unable to confine, nor unable to revoke; they are strictly more expressive of least-authority policy than ACL systems and avoid the confused-deputy class of bugs by construction.

Tags

#capability-security #ocap #security-myths #confinement #revocation #facets #access-matrix #mark-miller #foundational #srl-2003-02

Summary

Rees describes Scheme 48, a programming environment whose design is guided by operating-system security principles. The security kernel is W7, a call-by-value lambda-calculus with extensions for abstract data types, object mutation, and hardware access. Each user or subsystem runs in a separate evaluation environment holding the objects representing that user’s privileges; because environments determine availability of object references, protection and sharing are controlled by construction.

The paper describes experience with Scheme 48 as the programming environment for Cornell’s mobile robots (no underlying OS) and as a secure multi-user workstation environment, arguing that lexical scope + first-class environments are a natural substrate for capability-style security among cooperating agents.

Key Ideas

Lambda-calculus as minimal security kernel via capability-style environments.

Scheme 48 (W7): modules, macros, dynamic isolation, portable across platforms.

Trust mediated by controlling which names bind to which objects.

Authentication via capsules (tamper-proof labelled objects).

Applied to robots and multi-user Scheme environments.

Conceptual Contribution

Claim: Lexical scope and first-class environments in a lambda-calculus variant (W7) are a sufficient security kernel: protection reduces to controlling which names bind to which object references.

Mechanism: Implements Scheme 48 as a capability-style environment where each user/subsystem runs in its own environment; authentication via capsules (tamper-proof labelled objects); deployed on Cornell mobile robots (no OS) and as multi-user workstation environment.

Concepts introduced/used: Capability Security, Lambda Calculus, Lexical Scope, Scheme 48, Capsules, Distributed Security, Multi-Agent Systems

Stance: foundational / engineering

Relates to: Provides a principled, capability-based alternative to the input-validation discipline of Seven Turrets Of Babel and the static DDoS analysis of A Language-Based Approach To Prevent DDoS; relevant to sandboxing malicious tools described in MalTool Malicious Tool Attacks.

Summary

The second paper in Spritely’s three-part design series, this whitepaper lays out the technical core of Goblins — a distributed, transactional, object-programming environment built around object capability security (OCap). The thesis: secure peer-to-peer applications should feel like ordinary programming, not like a separate security discipline, and capability security makes that achievable. The operative slogan is “If you don’t have it, you can’t use it” — authority is conveyed only by holding a reference, never ambient.

The paper works through (1) capability security as ordinary reference-passing, motivated against Access Control Lists and the confused-deputy problem; (2) Goblins itself — a distributed object programming model with promise pipelining, vats as containers of synchronous turns, turns as cheap local transactions, and time-travel debugging; (3) OCapN — a new cross-implementation protocol for secure distributed object communication; (4) portable encrypted storage for capabilities; (5) library/application safety implications. Implementations exist for Guile and Racket Schemes, with a roadmap toward language-heterogeneous object invocation.

Goblins is the modern distillation of a three-decade lineage running through Mark Miller’s E language, the CapTP protocol, Jonathan Rees’s capability-kernel argument, and Carl Hewitt’s actor formalism. It reframes agent communication as object-reference passing over the network, offering an alternative substrate to the ACL/RPC-stack approach that dominates modern LLM-agent protocols.

Key Ideas

Principle of Least Authority (POLA): grant each piece of code only the authority it needs, no more

Object capability security: authority = unforgeable object reference. Lexical scoping + no ambient authority + no global mutable state

Confused-deputy problem: why ACLs fail when a privileged program is tricked into acting for an attacker

Vat: an isolated synchronous execution context; objects live inside vats; vats communicate asynchronously

Turn: an atomic event loop iteration inside a vat; turns are transactional — errors roll back the turn’s local state

Promise pipelining (from CapTP): chain calls on a reference before the prior call resolves, reducing round trips

Time-travel distributed debugging: replay turns deterministically across the network

OCapN (Object Capability Network): protocol for secure, cross-language distributed object invocation

Revocation and accountability as programmable patterns over references

“If you don’t have it, you can’t use it” — the design-level simplification capability security provides

Conceptual Contribution

Claim: Secure peer-to-peer applications become routine when authority is conveyed only by holding an unforgeable object reference — no ambient authority, no global mutable state, lexical scope as the capability kernel — and when the network distribution of such references is itself designed as an ordinary message-passing object system.

Mechanism: Goblins realises the E-language tradition in Scheme (Guile, Racket): objects live in vats; each vat runs atomic turns that serve as cheap local transactions; asynchronous inter-vat invocation uses promise pipelining to collapse round-trips; persistence, upgrade, and cross-language interop are handled by OCapN — a capability-preserving transport protocol. Time-travel debugging exploits the turn-level determinism.

Concepts introduced/used: Object Capability Security, Principle of Least Authority, Ambient Authority, Confused Deputy, Vat Model, Turn (Goblins), Promise Pipelining, OCapN, CapTP, E Language, Time-Travel Debugging, Capability Revocation

Stance: engineering / foundational design doc

Relates to: A modern engineering culmination of the capability-security thread rooted in Security Kernel Lambda Calculus (Rees 1995, explicitly cited) — lexical scope as a capability kernel, extended into a full distributed system. The vat model is a direct descendant of A Universal Modular Actor Formalism for Artificial Intelligence (Hewitt 1973) and sibling to Programming Erlang Second Edition but with security-by-reference as a first-class concern. Frames a structural alternative to the modern LLM-agent protocol stack: where Agent-to-Agent Protocol / Model Context Protocol / Agent Network Protocol layer trust on top of ACL/RPC primitives, OCapN encodes trust in the reference graph itself. The flat context trust model that ClawWorm Self-Propagating Attacks Across LLM Agent Ecosystems exploits and that MalTool Malicious Tool Attacks, AI Agents Under Threat catalogue is precisely the ambient-authority failure capability security is designed to prevent — making Goblins / OCapN a serious candidate substrate for Inter-Agent Trust Models - A Comparative Study’s Constraint trust dimension.

Capability Myths Demolished

Reference

Summary

Key Ideas

Connections

Conceptual Contribution

Tags

Backlinks