Linux, IRIX, and "POSIX Capabilities"

[Ka-Ping Yee]

On Sun, 7 Nov 1999, Tyler Close wrote:
> My Thesis
> ---------
> 
> Capabilities are most needed for distributed computing and
> are not essential at the OS level.

Interesting.  Okay, let's debate this one for a while.

> Point 1: Objects of value have a specific location
> --------------------------------------------------

Granted.

> 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.

Here is where i see that the whole key to your argument
rests.  Can the client really be sure of this if she is
not running a capability-secure operating system?

> 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.

This is exactly what Java attempts to do.  So far, it has
failed -- there are many ways for a Java applet to engage
in surprising behaviour, and the situation does not appear
to be improving.  This of course is not to say that such
protection is impossible without capabilities, but it does
make me quite skeptical.

Exactly how is it possible to confine client software in
such a way that it has access to the network resources
needed to engage in the transactions the user wants, and
nothing else?  Are we not still faced with the problem of
the user running all kinds of untrusted software on his
or her machine?  Once a single piece of such software
compromises the machine, the entire TCB is compromised;
the operating system can be manipulated, and so on.

What is to prevent my installation of Microsoft Internet
Explorer 5.0 for Linux from {abusing my authority to write
to my personal settings file} in order to {secretly modify
the Netscape browser plug-ins in my home directory so that
{the next time i use Droplets {my browser issues, on my
behalf, {a request to transfer funds from my e-gold account
to a Microsoft Wallet}}}}?

> 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.

This seems to be treading on pretty thin ice.  If the
human user of the TCB has limited capacity for determining
the appropriate security settings, then he is likely to be
overwhelmed by the details of correctly setting up his ACLs.

Are we agreed that ACLs are trickier to administer than
capabilities?  They seem that way to me (adjusting lists of
permitted entities on a variety of objects, rather than just
presenting an application with a fixed set of capabilities
when it starts up).

> 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.

Independent of the above argument (which i think is very
well worth having), let me be clear that this doesn't mean
we have to go to war with Linux.  I'm raising all these
questions precisely to try to figure out what the correct
strategy is -- some options appear to be:

    a) leave Linux alone, and interoperate, as Tyler suggests;

    b) build a capability abstraction on top of the Unix
       security model somehow, which people can then write
       trustable applications against;

    c) advocate changes to the Linux security model;

    d) advocate a move to a new underlying operating system.

I welcome other options anyone may care to suggest.



-- ?!ng