Anti Cap Quotes

"On the Inability of an Unmodified Capability Machine to Enforce the *-Property"

--title of famous paper by Earl Boebert

"A major problem for capability systems is a fundamental inability to solve the confinement problem, ..."

--Paul Karger, "Improving Security and Performance for Capability Systems" Technical Report 149, University of Cambridge Computer Laboratory, 1988. (Ph. D. thesis.)

"... an unmodified or classic capability system cannot enforce the *-property or solve the confinement problem"

"Since a capability is just a bit string, it can propagate in many ways without the detection of the kernel or the server ..."

--Li Gong, "A Secure Identity-Based Capability System” Proceedings of the 1989 IEEE Symposium on Security and Privacy, p. 56–65. Won best of paper at that conference.

"Capability systems modeled as unforgeable references present the other extreme, where delegation is trivial, and revocation is infeasible"

--Chander, Dean, Mitchell, "A State-Transition Model of Trust Management and Access Control” Proceedings of the 14th Computer Security Foundations Workshop, June 2001, p. 27–43

'But there were numerous open questions about the definition of secure state, of how one attained an initial secure state, how individual accountability could be established in an environment where capabilities were inscrutable, and where possession of a capability could conceivably be used by a Trojan horse. Rajunas was funded to assemble a workshop to investigate assembling a set of interpreted criteria for evaluating a trusted capability base operating system.

I requested that Earl Boebert, who led a project to develop a system based on PSOS, the Secure Ada Target (SAT), write a paper for an NCSC Conference showing that multilevel security confinement could not be assured in a pure capability based operating system.[4] A year earlier, Paul Karger had written a paper [29] on a design that augmented capabilities to overcome such intrinsic shortcomings.

About this time, I heard Butler Lampson's observation: "Capability based systems are the way of the future—and they always will be." '

--Marvin Schaefer, "If A1 is the Answer, What was the Question? An Edgy Naïf's Retrospective on Promulgating the Trusted ComputerSystems? Evaluation Criteria" Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC'04) https://www.cypherpunks.to/erights/elib/capability/duals/schaefer.pdf

"Used as capabilities, Java objects would have all the traditional problems of capability systems, e.g., difficulty tracking and controlling who has access to various system resources."

--Richard Drews Dean, p41, "Formal Aspects of Mobile Code Security", PhD thesis, Princeton, 1999 http://www.cs.princeton.edu/sip/pub/ddean-thesis.pdf

"Though popular, capability mechanisms are poorly suited to providing policy flexibility, because they allow the holder of a capability to control the direct propagation of that capability, whereas a critical requirement for supporting security policies is the ability to control the propagation of access rights in accordance with the policy. The enhancements introduced by Hydra and KeyKOS are intended to limit such propagation, but the resulting systems still generally only sup-port the specific policies they were designed to satisfy, at the cost of significant complexity that diminishes the attraction of the capability model in the first place.

Primarily with an interest in solving the problem of supporting a multilevel security policy within a capability-based system, a few capability-based systems (e.g., SCAP [25], ICAP [18], Trusted Mach [4]) introduced mechanisms that validated every propagation or use of a capability against the security policy. Kain and Landwehr [23] developed a taxonomy to characterize such systems. In these systems, the simplicity of the capability mechanism is retained, but capabilities serve only as a least privilege mechanism rather than a mechanism for recording and propagating the security policy."

--Spencer, Smalley, Loscocco, Hibler, Andersen, Lepreau, "The Flask Security Architecture: System Support for Diverse Security Policies", http://www.cs.utah.edu/flux/fluke/html/flask.html

"However, an important issue is confinement of privileges [26]. It should not generally be possible for one program to delegate a privilege to another program (that right should also be mediated by the system). This is the fundamental flaw in an unmodified capability system; two programs which can communicate object references can share their capabilities without system mediation. This means that any code which is granted a capability must be trusted to care for it properly. In a mobile code system, the number of such trusted programs is unbounded. Thus, it may be impossible to ever trust a simple capability system."

--Wallach, Balfanz, Dean, Felten, "Extensible Security Architectures for Java. In Proceedings of the 16th Symposium on Operating Systems Principles, 1997, p. 116–128. http://www.cs.princeton.edu/sip/pub/sosp97.html. Award winning paper at its conference.

CategorySecurity CapabilitySecurityModel CapabilityMythsDemolished CapabilitySecurityDiscussion