[cap-talk] Selling capabilities programming

[James A. Donald]

James Donald writes:
 >> The example case where capabilities are compellingly
 >> useful is the case of a powerbox granting file access
 >> to a particular file - and such a capability should
 >> be inherently transient - indeed it should not be
 >> possible for a powerbox to create and issue durable
 >> capabilities - there should be no general mechanism
 >> available to represent a communicable permission that
 >> is not transient.

David Wagner:
 > I think you mean "an example case where capabilities
 > are useful", instead of "the example case".  The
 > powerbox is not the only such case.

You neglect the word "compellingly".  Lots of things are
useful, but any turing machine can do anything any other
turing machine can do.  Capabilities are *compellingly*
useful in that they facilitate a user interface for
security that combines designation with permission, thus
allowing considerably finer grained permissions, and
thus less authority for each particular application.

David Wagner
 > [...] powerboxes should grant transient capabilities.

Conversely, when the user issues a durable permission,
he does not intend that permission to be communicated.

In practice, users do not want to issue durable
permissions at all - the implications are inherently
unclear.  They are aware that they cannot do so safely.
The user interface tends to be troubling at best
(Microsoft) and bloody awful at worst (unix).

 > I do not agree that it follows that object capability
 > systems must never admit even the possibility of a
 > durable capability.  That doesn't follow. Another
 > possibility is to construct the powerbox
 > implementation so it will only return transient
 > capabilities.  That seems like a perfectly reasonable
 > approach to me.

Any turing machine can do anything any other turing
machine can do, so perhaps it is better to restate the
problem in terms of user interface design goals:

Programs should be installed by a highly privileged
install script interpreter which interprets untrusted
scripts provided with the program - scripts that are
normally written with the good of the user in mind, but
could be written to attempt to install malware or
trojans.

The install script interpreter constructs an uninstall
script guaranteed to successfully uninstall the program,
by default leaving behind program configuration
information, and data stored by the program after
installation, but removing all originally installed code
and data and all permissions.  Install scripts are
untrusted, uninstall scripts are trusted.

Packages should be installed in a program directory that
*only* the install script interpreter has general write
access to.  User cannot delete stuff, except by
uninstalling, cannot modify stuff, cannot even browse
the directory except by viewing the uninstall list.

Every installable package, every group of programs with
a single install, gets read access, optionally write
access, to its program's directory in the program
directory, but no others in the program directory,
cannot even browse them.  The install script for a
package can grant other installed packages access to its
own directories, (and discover that the other module
does not exist if it gets an error) but cannot grant its
programs access to another module's directory.  Running
programs can discover what modules have given them
access, but cannot discover what other modules exist.

There are per user directories, the equivalent of unix
home and Microsoft "My documents" which are created when
a user is created, and per user and program combination
directories, which may be created (if the install script
requests that this be authorized) when a program is
first run by a particular user, the equivalent of
Microsoft's "application data" directories.   There is
also a "shared documents" directory that all users can
read from and write to, and an analogous "application
data" directory.  There is a "my public documents"
directory that all users can read from, and only each
particular user can write to.

Most programs can only read from or write to "my
documents", "shared documents", and "my public
documents" and so forth through a powerbox, but they can
read and write their particular directories at will.

You will notice two things about this description:  One
is that the user will never have strong need to set or
modify permissions, so we do not much care how horrid
the user interface is for modifying them.  (None of the
evils of Polaris.) The other is that all of the
permissions described are durable, and none of the
permissions described are ever intended to be
communicated.  The natural language description of this
system is terms of privileges belonging the entities,
ACLs.

Now with "protected" capabilities, one can of course
protect a durable communicable permission from ever
being communicated, but this seems a rather backwards,
complicated and risky way of solving a problem whose
natural language description is terms of privileges
belonging to particular entities and exercised only by
those entities.