August 26, 2008
What are capabilities?
OKL4 2.1 is the first public release of an L4 microkernel (and, I believe, the first commercial modern microkernel or hypervisor) that uses capability-based protection. But what does this mean?
Capabilities (caps) are an operating-system security concept. They are tokens conveying access rights, often likened to keys. Presentation of a valid cap is enough to be granted access to a particular resource. So an "agent" (user or program) in a system has a set of caps (often represented as a clist, short for capability list) which represents the set of rights the agent has in the system.
This is in contrast to an access-control list (ACL) model used traditionally as the basis of security in operating systems (examples are UNIX file mode bits and Windows ACLs). ACLs store access rights with objects, while caps store them with subjects (aka agents). What difference does this make?
Quite a bit, from the security point of view. Unless the system is very static (eg. only has a fixed number of processes), it is unfeasible to have an ACL entry for each individual agent that might access the object. (Imagine a Linux system where all access rights needed updating whenever a process is created or exits.) Hence, for the purpose of access rights, agents are grouped — usually by associating them with a user ID — and having permissions refer to that UID.
The drawback of this is that it is now impossible to restrict the rights of some of the processes of a particular user. This issue is exemplified in the well-known confinement problem, which is, in general, unsolvable by ACL-based systems. Typical examples are digital rights management and running untrusted code (maybe downloaded from the web) without having to trust it not to steal or damage your data. ACL-based systems require extra hacks (eg chroot jails) on top of the basic protection system to enable some limited forms of confinement.
These drawbacks are overcome with capabilities. The fact that caps refer to individual objects makes cap-based protection much more fine-grained and thus flexible. A process only has the rights conferred to it by its clist, and by tailoring clists, access rights can be finely controlled. A process can be confined by only giving it enough caps to access its own code plus any input data it may need, plus the minimal rights requrired to store its outputs (or access output devices).
These are some of the reasons why caps have been the preferred security mechanisms in the security community for many years, and why ACL-based mainstream OSes (such as Solaris and Linux) have recently started to add them (making their protection system even more complex and messy).
With OKL4 releae 2.1 we have made a start towards a clean and powerful protection model based on capabilities. In 2.1 caps are used to assign IPC rights — these co-exist with other (ad-hoc) protection mechanisms for other resources for the time being (you can't overnight completely change a system that's deployed in the 100s of millions). Future releases will make all other resources subject to cap-based access control.
One of the beauties of caps is that they provide a nice mechanism for delegating authority. In previous versions of OKL4, resource delegation was impossible, the root server controlled all resources. In the next release, delegation will be possible (removing the privileged status of the root server), but initially static (defined at configuration time). The full capability model will provide fully-flexible dynamic protection management, including dynamic delegation. This will make OKL4 a platform that combines maximum flexibility with highest security.
Posted by Gernot Heiser on August 26 at 05:23 PM
About Gernot Heiser:
Gernot Heiser, Chief Technology Officer, never thought he would be in the business world. Prior to NICTA's creation in 2003, Dr Heiser was a full-time faculty member at the University of New South Wales. However, this die-hard academic couldn’t pass up the opportunity to see the commercialization of this research. Gernot still loves teaching, almost as much as he loves good wine and good food. And anyone will tell you that Gernot knows his wine.