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:
- 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 and extra bits in memory that the hardware uses to discriminate between data and caps.
All of the hardware support for capabilities that I have seen presumes some software support to complete the system.
- Kernel (as in Unix FD)
- Unix and Linux are not capability systems but those kernels have elements of capability ideas.
Most of the systems named here have capability aspects.
seL4 is an important new capability kernel.
All of the capability kernels I have seen require at least 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 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 most 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 is an important exploitation of these ideas.
OAuth 2.0 is better known but not as flexible, I think.
- trusted network
- I propose some very preliminary ideas here.
‘Trusted network’ may sound paradoxical, but a PCIe network may extend only inches.
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.
Crypto systems are likewise excluded.
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.
There are protocols to link CPU or Kernel capability systems over reliable communication links.
Where do these fit?
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.
Some propose that there is a new world here.