Linux, IRIX, and "POSIX Capabilities"

Tyler Close
Sun, 7 Nov 1999 23:33:22 -0500

Ping wrote:
> is a big step forward.  This is the really
> important question,
> and i would really like to solicit some opinions
> and deep thinking
> on this issue from all of you guys.

You may see this as heresy, or a punt, but I'm going to
bring it up anyway before we start a crusade.

My Thesis

Capabilities are most needed for distributed computing and
are not essential at the OS level.

Point 1: Objects of value have a specific location

Let's start by gaining some insight from a familiar
protocol, ERTP. The ERTP covers some very important ground.
It forms the basis for a capability based electronic
marketplace and serves as an indication of the applications
yet to come.

In ERTP, all Purses must be in the same TCB as the Issuer.
These very valuable software objects must be located at a
given spot and they don't move. Interaction with these
valuable objects is determined by how the server TCB has
defined the borders of the TCB. The security of the Issuer
is only based on the security of the host TCB, and no other.

I believe that this location binding will apply for all
objects of value. Furthermore, a shared resource, like a
document or database is also necessarily bound to a
particular location by the need to keep updates ordered.

Since things of value are confined to a given location. We
only have need to secure that one location and provide a
flexible means for accessing that location. This need is
filled by any OS that can limit it's doorways to software
that imposes capability semantics. Proof of this is the TCB
running on the site.

Point 2: Client TCBs have a limited range of permissions to

No secure interaction can take place unless the client also
has a secure TCB. An ERTP Issuer may not care if a Purse
holder has their erights stolen due to a leaked capability,
but the Purse holder certainly cares.

In order to prevent such theft, the software embodying the
client's TCB must be prevented from acting under the control
of parties other than the client. The only feature needed to
accomplish this is confinement. The client software must be
prevented from doing a range of things such as: opening
connections to arbitrary network addresses, reading
arbitrary files from the hard drive, etc. The number of
resources to be controlled here is limited. As discussed
above, most things of value that the software will use will
be located on external TCBs that must be interacted with
according to the semantics defined by that external TCB.

Not only does the client TCB have a limited array of
resources to protect, but the human user of the TCB has a
limited capacity for thinking about the use / protection of
these resources. Whether capability or ACL, the user will
only be willing to make a very limited number of settings,
if any at all. ACLs are more than sufficient for such large
grained administration of permissions.


Let's not push the Linux folk into accepting something they
are both unwilling to accept and ill equipped to provide. It
will only cause strife.

Our only goal is to ensure that the word 'capability', and
the body of theory that this word represents, remains
uncluttered. We will need this word, authority and good will
when propagating our distributed capabilities. Since this is
the only essential victory, let's save our strength for
those battles.