Some recent platforms assume implicitly that the main security problem is the excess authority of applications.
From that perspective the natural solution seems to be manifest entitlements or endowments, enforced by the kernel.
Such solutions, as in IOS or Android, address the famous <a href=http://www.cs.berkeley.edu/~daw/talks/PLAS06.ps>solitaire example</a>, and some conclude that it remains merely to refine these pieces of authority.
Capabilities as a platform architecture go far beyond entitlements and I argue here that while entitlements help, they only scratch the surface of the problems.
<p>
<a href=http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/documents_top.html>Mach</a> moved the file logic of classic kernels into one object with its own protected state.
There were no walls separating my file state from your file state; the logic of the file code had to keep the state of its clients separate.
In Keykos I got a new instance of a file object when I opened or created a file.
If I discovered a flaw in the file code I could corrupt the state of my file but as long as you stayed within normal file usage, your files behaved as documented.
An exploited bug in the Mach file system could corrupt all files.
<p>
The Mach kernel architecture was good enough to do it like Keykos but either it did not occur to them or they chose not to for performance reasons.
In Mach the only object in sight was the file system, not the file.
I suspect that they merely thought it was too radical.
Out performance was excellent.
Similar patterns and contrasts with Mach are found for most of the kernel functions.
<p>
In our early emulation of the Unix environment there were files within that were not Keykos objects.
We realized our error and changed it so that the Unix file was just a Keykos segment which could then be dynamically shared with the native Keykos world.
Our modularity improved and our code shrunk.
This pattern was repeated a couple of times over and it could be carried further.
<p>
Keykos programs written to work at primitive levels thus rely, even indirectly, on a very limited amount of code.
In Mach, Capsicum, IOS, Android, there remain gigabytes of code whose bugs can bring down or corrupt your app, even when your app does not explicitly rely on that code.
In Keykos 300 KB of kernel and 200 KB of space bank were about the only code that was in the TCB of just about any app.
It was possible to avoid the space bank but that was rare.
The attack surface is thus about at least two orders of magnitude smaller and I claim that this delivers radical reliability which was the thrust of Shapiro’s work.
<p>
There are many other benefits to capability architecture beyond minimization of the TCB.
Getting from here to there remains a conundrum.