Kinds of Capability System
Capability ideas have been invented several times.
They appear in these contexts:
Matt Rice contrasts (cap kernels with segregated storage) with languages relying on memory safety thus:
- Cap CPU; (ISA)
- Hank Levy’s book recounts the history of hardware implementations of capabilities thru the Intel 432.
An important division in this category is between segregated capability storage (Plessey 250) and extra bits in memory that the hardware uses to discriminate between data and caps (System/38 & CHERI).
All of the hardware support for capabilities that I have seen presumes some trusted software, unconstrained by cap rules, to complete the system.
Currently CHERI tries to preserve important elements of Linux, based upon the more general Capsicum ideas of capability savvy hardware.
- Capability Kernel upon conventional CPU
- Unix and Linux are not capability systems but those kernels have elements of capability ideas.
Most of the systems named here have capability aspects.
Keykos, Coyotos and seL4 are pure capability kernels.
All of the capability kernels I have seen require at least a privileged mode hardware feature so that the kernel can maintain control.
- Language (sort of type safety)
- You can sense capabilities in Alonzo Church’s work in the 30’s and 40’s.
In the last few decades computer language designers have been discovering and adapting ideas from Church’s ultra simple Lambda calculus, in which I see capabilities.
Java’s JVM is a software platform with something close to capability security.
It is close enough to convince me that such a platform could support programs in multiple computer languages interacting by capability discipline.
- Public key technology supports many capability patterns across untrusted networks of computers.
Mark Miller pointed out early that knowing a public RSA key was like holding a capability and knowing the corresponding private key was like being the designee of the capability.
The public key fails to locate, however.
SDSI are an important exploitation of these ideas.
OAuth 2.0 is better known but not as flexible, I think.
While crypto supports distributed capability designs and capabilities spawn crypto ideas, crypto by itself is not a capability system for it fails to limit other causal paths in an extended computation.
- trusted network
- I propose some very preliminary ideas here.
‘Trusted network’ may sound paradoxical, but a PCIe network may extend only inches, well within some security perimeters.
Some language capability systems rely upon memory safety, in the same way that a kernel relies on the MMU, in essence creating a partition between the languages runtime and the running program for hiding the capability bits.
I propose “capability system” to describe systems that are able to limit the actions of programs in acquiring and transmitting information, to capability means.
This is the basis on which I exclude Unix and crypto.
These various technologies mainly complement each other.
They each do well standing alone specializing in solving classes of security problems.
I claim just now that the capability kernel solves perhaps the most pressing security problems without boiling the ocean.
Mark Miller asks whether UIs with “authorization via designation” count as another category.
I would say no because those I have included incorporate untrusted code whose ability to harm is limited by lack of capabilities.
Such ideas might be extended to form a graphic capability platform.
I fear that it would be complex.
There are protocols to link Kernel capability systems over reliable communication links.
I would like to say that a “complete capability system requires” a place to insert code or behavior that wields capabilities so that patterns such as attenuation are possible.
This needs more precision.
This category might exclude IBM’s System 38 and its subsequent lineage.
IBM seems to have thought that no programmer outside IBM could understand invoking a capability.
The first three plans, CPU, Kernel, Language, each posit a closed system of capabilities.
This limitation may usually be transcended by invisible virtual remote capabilities.
Some software platforms survive space and time hogs — programs that keep allocating space until there is no more, or never terminate.
Just now I do not know of any attempts to make language based systems survive space or time hogs.
The E vats provide some protection here that I do not understand.
Some propose that there is a new world here.