New Software Layers

  1. 🤨 Capability Kernel (all the privileged (supervisor mode) code)
  2. Capability confined miscellany:
    1. 🤨 Allocators, with nearly exclusive raw access to necessary things like space and time. Temporary access to refined versions of such things is up for lease.
    2. 🤨 Various shared mutable objects for cap mediated interactions among tenants.
    3. 😀 Merely convenient things you could do for yourself.
  3. 😀 Virtual legacy environments are a motley collection of whatever is necessary to accommodate legacy programs. Some legacy environments host more than one legacy app and allow legacy style communication between them. Legacy apps from different platforms can co-exist in this new world. ‘Legacy apps’ includes most utilities. It makes sense to include even Unix shells to operate in neighborhoods. Objects, such as files, are produced and consumed by legacy apps using legacy APIs, but they also appear as native capability objects, segments in the case of Keykos. With such disguises legacy apps pass as native.
  4. 😀 Native applications designed for a cap system. By ‘native’ I mean how a capability savvy app expects to see it, via a capability.
  5. 🤨 Paranoid’s layer, whose purpose is to understand and selectively permit communications between contexts of which they maintain some theory—to help the user do the right security thing. Capability theory is the tool of this code.
The icon “🤨” is for objects that you use which must be available to programs you don’t trust. That software must guard against maliciously crafted requests that may be designed to corrupt the service you use. The “😀” is for services that behave correctly for benign requests.

Together layers 1 and 2 provide most legacy kernel functions, but in unconventional forms. They exist for Keykos and a good start on layer 3 is available today, except that code does not quite match modern hardware. They are available under an MIT style license. Design and code bugs in layer 2 do not breach the walls established in layer 5, in contrast to legacy monolithic kernels.

Legacy apps are not included here because they are not new, but they remain useful. They are a transplanted old layer, not a ‘new layer’. They are the only programs that are not cap savvy. They each see a nearly empty universe, if they are curious enough to look.

Legacy apps employ layer 3 exclusively. Layer 3 relies on layers 1 and 2 but is constrained to capabilities provided by the logic of layer 5. Capability savvy apps rely on layers 1 and 2 and fit wherever appropriate in a cap system especially within the contexts defined by layer 5 software.

Embedded

Note that this whole plan preserves legacy hardware and legacy applications. You can omit layers 2.2, 3, 4 and 5 and get a secure barebones platform. That is sort of where seL4 is at now but I think they can’t swap their objects. By definition layer 3 is harmless. I bet that someone running a power plant will have a vital app to two for which the sources are unavailable. In that case a fragment of layer 3 will suffice.

I record here an idea because it does not fit elsewhere. A filter is a program that strips extraneous signals from clipboard messages that might be delivered to gullible programs. For instance the content of a clipboard might be produced by a compromised app and delivered to a gullible app in order to compromise it. This can be generally avoided if the clipboard content is stripped down to mere printable ASCII text and shown to the user for confirmation. Such a filter can be installed as appropriate by layer 5.

Layer 5 is responsible for securely telling the user where the walls are. It is also responsible for allowing the user to rearrange these walls, perhaps within limits. If iOS or Android adopted layers 1 and, 2 I suspect they would eventually find it superior and use it in all their offerings. UI designers could and might build their own layer 5 software that would provide almost exactly what their customers see today. I suspect it would take rather less software and fewer bugs as well. Perhaps a spectrum of layer 5 software between the extremes would come about. I would reflexively design a paranoid version. The design of layer 5 is where there are vast differences in what the user:

In each context UI designers will find their job easier. I want to emphasize that security and luxury are compatible. I have yet to convince myself that a typical user can conceive of the implicit walls. Perhaps a radically different screen style would help.

Section 3.7 of this paper discusses legacy apps situated in a capability system in a somewhat different approach.