Ben Laurie blathering

Capability Operating Systems

Now that we’ve deployed the most successful capability language ever, it’s time to start thinking about the rest of the stack, and one end of that stack is the operating system.

Luckily, thinking in this area has been going on a long time – indeed, capabilities were invented in the context of the OS, though for a long time were thought to be the exclusive domain of specialised hardware. Some of that hardware ended up being extremely widely deployed, too, so don’t think this is the stuff of lab experiments only. Sadly, though, despite the hardware supported capabilities, these were not generally exposed up to the level of the kernel/userland interface; they were thought to be useful only within the kernel (with one notable, but not very well known or widely used, exception),

However, more recently it has been realised that capabilities are not only useful in userland, but also can be implemented on top of commodity hardware, resulting in a crop of new capability operating systems. But these still suffer from the problems that traditional capability languages have suffered from: they need the world to be completely reinvented before you can use them. Because the capability paradigm is fundamentally different from the ambient authority ACL-based world we live in, no existing software can fully enjoy the benefits of capabilities without at least some rewriting.

So, the interesting research question has now become: how can we move toward this world without having to rewrite everything on day one? Some progress has been made with mapping POSIX onto capabilities. Heading in a completely different direction is the idea of running existing OSes as guests on a capability system. Yet another approach is to apply capabilities to more restricted domains: one that I have been involved in is the idea of hosting untrusted software “in the cloud”, in the same vein as Google App Engine. Because this software is all new, changing the way it has to work is not a big deal.

But the thing that interests me most is the work being done on FreeBSD, which allows capability-based code to coexist with (or even be contained within) existing POSIX code. This provides a genuine, believably workable, migration path from existing systems to a brave new capability world. We can move one application (or even one library) at a time, without breaking anything. Which is why I am pleased to be able to say I am involved in this work, too. What’s even better is this work is by no means specific to FreeBSD – the same principles could be applied to any POSIX system (so Linux and Mac OS X would be good targets). Just as we have seen success with Caja it seems to me that this route can deliver success at the OS level, because it allows a gradual, piecemeal migration.

Unusually for me, I have not interrupted my narrative flow by naming or saying too much directly about the various things I link to – however, I appreciate that following links in the middle of reading can get distracting, so here are many of the links again with some explanation…

Caja: a capability version of Javascript. I have written about it before.

CAP computer: the project that invented capabilities.

IBM System/38: more capability hardware.

AS/400: derived from the System/38. Although this had capabilities, they were not exposed to userland. Very widely used commercially.

KeyKOS: a commercial capability operating system.

Amoeba: an experimental capability system – like Caja, it tends to advertise its other virtues rather than describing itself as a capability system.

EROS: another experimental capability OS – originally intended to provide robustness, not security. The first to run on a standard PC.

CapROS: when EROS was discontinued, it lived on as CapROS. Google has recently sponsored the development of a web-hosting experiment on top of CapROS.

Coyotos: by the original designer of EROS. Now also discontinued (can you spot a trend here?).

Plash: the Principle of Least Authority Shell. This shell runs on Linux, figures out from the command line what any particular invocation of an executable should have access to, creates a sandbox with access to only those things, then maps POSIX calls onto the sandboxed things.

L4: a modern capability-based microkernel.

L4Linux: Linux running on top of L4. Although this is nice for things like driver isolation, it seems like the wrong direction because it does not assist with exposing capabilities to userland.

FreeBSD Capsicum: a capability mode for FreeBSD. Whole executables can opt in to this mode, coexisting with POSIX binaries. Even more interestingly, libraries can spawn off capability-mode subprocesses whilst effectively remaining in POSIX mode themselves. This allows the transparent implementation of privilege separation. This project has also been sponsored by Google.


  1. I think there is an interesting comparison to be made regarding “most successful capability project ever” (although I know you limited your claim to “language” only) between Caja and OKL4 [1], although how one compares apples with apples here I have no idea. OKL4 has, I believe, been deployed on a hell of a lot of mobile phones.

    Also of note, of course, is the formally verified counterpart to OKL4, namely seL4 [2].

    Finally, my favourite pure capability OS design (in terms of usability and familiarity from the point of view of the application programmer) is still Unestos [3].




    Comment by Toby — 28 Mar 2010 @ 10:42

  2. Hi Ben, nice post! Two nits:

    Capabilities were first invented by Jack Dennis & Earl Van Horn in a paper published, IIRC, as a tech report in 1965 and again as a paper in 1966 or 1967. Their design was first implemented as the PDP-1 Supervisor in 1969 — one year before the CAP. Charlie Landau, one of the KeyKOS architects and now the main CapROS guy, worked on the PDP-1 Supervisor.

    L4 is capability-like in some ways, but I don’t think it can be classified as a capability system. seL4, which is based on L4 but not open source, does seem to be a true capability system.

    Comment by Mark S. Miller — 28 Mar 2010 @ 17:36

  3. Don’t forget Native Client. Like Plash, it’s an OS-like sandboxing system that runs under a host OS. NaCl’s basic syscall interface is pretty much a capability system, albeit not an ideal one: communication with the outside world is done via socket descriptors, though some types of descriptor are not delegable.

    Unfortunately, the interface that the NaCl browser plugin provides is currently not very capability-friendly.

    Comment by Mark Seaborn — 28 Mar 2010 @ 18:27

  4. I’ve been thinking for some time that the idea
    that everyone can have a general purpose computer in their home is just wrong. The masses are not capable of keeping a G.P. computer secure. I don’t trust myself to run a Windows computer and keep it secure.

    I think that for the masses the future belongs
    to some descendent of the iPhone. It would be an appliance carefully designed for security and controlled by the vendor since the user is not capable of keeping it secure.

    The OS in such an appliance could be based on capabilities. Each “app” would declare what capabilities it requires when running and the OS would ensure that it gets no more than those capabilities. The capabilities would be finely divided e.g. cap- to send email, cap- to read the address book, cap- to send email to a particular address, cap- to access a particular set of web sites.

    The aim is to make it much easier for the vendor to review an app and discover what it is capable of and ensure that it is capable of no more than that.

    As far as I know Apple’s iphone is a long way short of this but its control of the app store is a good start. Perhaps google can show them how to do it properly.

    Comment by Anthony Shipman — 29 Mar 2010 @ 11:54

  5. L4 is not originally capability-based, but recent APIs got capabilities. This should not be seen as a retrofit, since in L4 as microkernel this is really more a question of the API that you want to expose towards your drivers, services and apps.

    To the best of my knowledge, NICTA’s recent version of OKL4 is going towards capability-based API due to results from seL4. The guys from Dresden are also working on a capability-based version of their L4 flavor. Their work tends to be more open-source-ish and much more usable as a development OS due to the many (abstraction) libraries, drivers, services and apps shipped as part of DROPS.

    I don’t know if they will port the DROPS environment or L4Linux to the new API but I guess so. They’re rather quiet about this..

    Comment by pepe — 29 Mar 2010 @ 16:59

  6. Other early capability-based systems were the Chicago Magic Number computer (xxx), CAL TSS for the CDC 6400 (, the Plessey 250 (

    See chapter 3 of:

    Comment by Paul McJones — 29 Mar 2010 @ 17:23

  7. Don’t forget Symbian which has a very mature capability model together with process isolation and IPC management

    Comment by Paul Todd — 30 Mar 2010 @ 15:43

  8. Plan 9 also has support for capabilities via its cap-device:

    The way it is used as part of the whole security framework is quite peculiar and interesting, for details see the excellent paper on Plan 9 security:

    Comment by uriel — 8 May 2010 @ 23:47

  9. […] mentioned FreeBSD Capsicum in my roundup of capability OSes earlier this year without mentioning that I am involved in the project. Since then we’ve managed to port and […]

    Pingback by Links » FreeBSD Capsicum — 14 Aug 2010 @ 12:34

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress