Three-paper Thursday: capability systems

This week, my contribution to our three-paper Thursday research reading list series is on capability systems. Capabilities are unforgeable tokens of authority — capability systems are hardware, operating, or programming systems in which access to resources can occur only using capabilities. Capability system research in the 1970s motivated many fundamental insights into practical articulations of the principle of least privilege, separation of mechanism and policy, and the interactions between program representation and security. They also formed the intellectual foundation for a recent renaissance in capability-oriented microkernels (L4, sel4) and programming languages (Joe-E, Caja, ECMAScript 5). Capability systems have a long history at Cambridge, including the CAP Computer, and more recently, our work on Capsicum: practical capabilities for UNIX. I’ve selected three “must read” papers, but there are plenty of other influential pieces that, unfortunately, space doesn’t allow for!

The first paper is HYDRA: the kernel of a multiprocessor operating system by Wulf, Cohen, Corwin, Jones, Levin, Pierson, and Pollack, which appeared in Communications of the ACM in June, 1974. This paper lays down in clear terms the notion of separating policy from enforcement through a capability system — and continues development of the idea of a microkernel (“nucleus”). Key to HYDRA is the the notion of an object capability system, appealing to co-evolving ideas of object oriented programming and run-time enforcement of encapsulation. HYDRA builds on the shoulders of other capability system work, such as CAP and the Rice R1, and occurs contemporaneously with work such as Neumann’s PSOS. Although the phrase distributed system is not yet in use, in this paper it becomes clear that software compartmentalisation for security inherently introduces distributed systems properties in local software designs — an issue we struggle with today (and that Fabry objected to in the move away from capability hardware architectures and towards message passing). Ideas from HYDRA have significant influence over many later systems, from Mach and L4 to Java.

The second paper is Protection in programming languages by James Morris, which appeared in Communications of the ACM in 1973. This paper is a key work linking ideas about programming language protection, especially the evolving concept of encapsulation for both reliability and security, and early work on object oriented programming. Insights into this form the foundation for a continuing thread of research exploring the tensions between program representation and enforcement. This paper makes natural background reading material regarding the evolution of programming language security as a common reference for projects as diverse as the JDK 1.2 security model, Joe-E, decentralised information flow control (DIFC), and others. It is hard to consider this work in isolation from related papers by Lampson and others, nor work such as Smalltalk, needless to say!

The final paper is an unpublished security analysis on the Combex DarpaBrowser by Wagner and Tribble, a capability-based web browser design grounded in the E programming language and run-time (developed by Marc Stiegler and Mark Miller). This paper makes for great reading because it both describes a fascinating security architecture linking language-level and run-time security properties, and an adversarial vulnerability analysis of that system. The authors describe both the strengths and weaknesses of the DarpaBrowser, exploring issues such as the mapping of policy goals into a capability system, what it means to try to make the principle of least privilege a practical design concern, user interface applications of the capability model, such as power boxes, and how vulnerabilities in the privileged execution substrate (a theme in adversarial literature dating to Karger and Schell’s Multics security analysis) undermine the approach. Like so many interesting security analyses, their conclusion is that the system is insecure but securable, leading to obvious points of discussion! Follow-on work from the same authors includes Joe-E which refines these ideas about the link between programming languages, runtimes, and security.

Work on capability security models remains extremely relevant, providing a foundation for thinking about security in many programming languages, distributed systems (compare and contrast: capabilities and certificates), web browsers, and more. These papers, and several others we will look at in future three-paper Thursdays, are drawn from the reading list of R206: operating and distributed system security, our 8-week masters-level research readings course in computer security. Our discussion of capability systems lead naturally on to R206’s next topic: programming language security, including the JDK 1.2 model, Joe-E, DIGC, and Reflections on Trusting Trust.

Which papers might you choose, if you had to pick just three, on capability systems?

Leave a Reply

Your email address will not be published. Required fields are marked *