First see Chip Morningstar’s recent comments and my detailed notes thereon.

Chip’s thrust will happen somehow if we survive long enough and now is the time to start. I want to push for a quick fix with early payoff for many critical problems. It is also a foundation for Chip’s larger project.

Like Chip I will be blunt. Current OS architecture is badly wrong. Fixing all the Unix or Linux or OpenBSD implementation bugs will not solve the problems. The same goes for Windows and Mac OS X. iOS and Android have moved 10% in the direction that I propose but as best I can tell they have done this by adding band-aids to a code base already far too complex. That the band-aids are approximately the right shape helps, but this is not a path to a solution. Current OS’s all assume that we supply global textual names for everything and much later decide how to say that some programs can’t access everything. These insights go back to 1965 and Dennis & van Horn’s PDP-1 system. I wish I could give a short snappy proof for these claims but today I can’t.

I do, however, make some bald claims:

For concreteness the ‘kernel’ is just that code that runs in privileged mode.

The new kernel forms the first layer and entirely upsets affordances of conventional kernels. The second layer is about 250 KB of code that define objects that provide convenient functions that civilize capability discipline while itself being confined by that discipline. It provides many familiar affordances — many in unfamiliar form. A third layer is composed of hacks to fool legacy code with virtual environments sufficient to get their jobs done. This layer provides familiar affordances in familiar form via system calls. Capability savvy code does not use or rely on this third layer. This third layer is not in the security “reliance set”. The third layer gets some credibility from the success of virtual machines which are known to actually provide useful environments. Here we report on some Keykos experience with such a layer. More recent virtual machines provide a tad of sharing without sacrificing security. Our safe sharing goes far beyond. There are many details to be filled in and I will miss some.

These claims are indeed bald but can be vetted at a minuscule cost compared to the issues that the press suggests. Regarding formal proofs.

In short we swap out the kernel and replace it with a much smaller capability kernel and a level of capability savvy logic, preserving the hardware and applications.

My claims are based on experience with Keykos. There are several similar technologies that might also serve.

Apple provides an impressive document on iPhone security. Apple’s considerations are nearly disjoint and complementary to these.

Keykos was designed for different purposes than what drives us here. Those original advantages survive, such as metering access to data, confinement, and quite a few more.

The Fifth Layer

A primary goal of the above disruptions is to make it easy to install in one machine a variety of contexts with known and limited ability to communicate. A fifth layer comprises tools to help the user create and understand these limitations and so exploit the safety they provide. I do not know any examples of such code. This is tentative and a bit fanciful.

We begin with a use case that has recently been in the news—the stealing of many e-mails of the DNC. Secure e-mail would seem to necessarily involve crypto. Each participant is assumed to have a computer running said system. Such a computer is configured with a context with circumscribed screen and keyboard access and no direct Internet access. There is a service that behaves as an Internet interface but which discards (perhaps with report) outbound messages except to a particular destination. Outgoing messages are, of course encrypted before reaching the Internet. Presumably there is a trusted mail server somewhere that each client machine accesses. Decrypted messages arrive from this pseudo Internet for treatment by a conventional Mail app who is unaware of the subterfuge.

The same mail app is probably available outside this context with unfettered Internet access. In cap terms these are two instances of the same behavior without access or knowledge of each other.

We speak of “circumscribed access” to refer to patterns that allow the user to know what context the pixels come from and to whom the keystrokes, and mouse actions are reported. For some users this knowledge will initially be conscious, but later unconscious. These are important issues in the design of the forth layer. Military security computers have done some work here but I don’t know how successful it is. There are a few ideas here.


To write:
Hardware Fidelity
Many Worlds
Open Security
What to do
Capabilities in the large/small
bullets
Bad Architecture Habits
Physical RAM access
New Software Layers
Formality
Googling “Proactive Cyber Defense”
How We Got Here
Speculation on why Silicon Valley does not move now
Customers
Thriving on Bad Code
I have the unconventional opinion that more vulnerabilities arise from misunderstanding the semantics of an object, than from mis implementing the object. I am a bit of a documentation nut.

much about OS X.
Android
There is much hype here, but also considerable value, I think.
US Commission
Succinct description of why caps are good

last year