Capabilities

[Gary D. Duzan]

   There seems to be some interest in using capabilities in MOOSE, and
probably an equal amount of confusion about them. Therefore, I'll take
the opportunity to put on my professor's cap and talk about them for a
bit.

   A Capability is just that: the ability to do something. An entity
that holds a capability has the right and ability to perform a
particular operation on another entity. To do something to something
else, you need to what you are doing it to, so capabilities incorporate
addressing as well. Therefore, capabilities include both naming and
security in a single concept. Capabilities may be passed to other
entities to allow them access to the capability-protected entity.

   A typical implementation will have an object id, method id, a set of
rights bits, and possibly a sub-object id (for large objects that
manage a set of smaller objects.) In a distributed system, it may also
contain hints about which system the object resides upon. The calling
entity would make a system call containing the capability and any data
to pass to the method. When the destination object receives the
message, it examines the capability for validity, and if valid,
performs the desired operation.

   Now, if capabilities were only normal structures, a malicious entity
could simply flip rights bits and do whatever it pleased. There are
basically two ways to deal with this problem: system capabilities and
encrypted rights.
   A system with system capabilities keeps all capabilities in a
protected space which normal entities cannot access. This system space
contains a table of the capabilities held by each entity in the system.
Instead of including the capability itself in the system call, the
entity passes an offset into its capability table. The system then
extracts the capability from the table and passes it to the destination
object. For the Unix people out there, this is something like the idea
of a file descriptor. Though I have no experience with it, I understand
that this is the method used in OS/400.
   A system with encrypted capabilities treats capabilities like any
other program data structure. To maintain the security of the
capability, the rights field, along with a random number generated by
the object, is encrypted, with the object holding the decryption key
(or keeping a table of encrypted rights -> rights mappings.) To forge a
capability, an entity would have to know the encryption method, the
encryption key, and the random number. This is the method used in the
Amoeba distributed operating system.

   Note that nowhere in this discussion is the concept of a user or
superuser mentioned. An object accepting a capability doesn't care who
holds it, as long as it is valid. In such systems, a user is just
another entity that holds certain capabilities. Capability systems will
also generally support a naming object to distribute capabilities. Such
an object would contain sub-objects which hold other capabilities.
These capabilities may refer to other sub-objects of the naming object
or to other objects in the system. In this manner, a single capability,
possibly representing a user, can expand to a full set of rights to
objects in the system.

   Capabilities have been around for a long time, but have never been
very popular. However, with the rediscovery of the powerful simplicity
of capabilities, and their implementation in the Amoeba and OS/400
systems, I believe we are facing the dawn of a capability renaissance
in operating systems.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts