[cap-talk] Selling capabilities programming

[James A. Donald]

James A. Donald:
> > A capability in this sense is a communicable
> > permission... At the implementation level, the
> > permission may be implemented as a value in a
> > sparsely populated address space that enables access
> > to an event queue through a filter...

Jonathan S. Shapiro wrote:
> That can be read a couple of ways. If what you mean is
> that a capability can be expressed as an unprotected
> data value that is protected by sparsity, then I think
> this is wrong. The result is not a "protected
> capability system", and necessarily suffers from all
> of the deficiencies identified by Boebert, Gligor,
> etc.
>
> Conversely, if the capability itself is protected, it
> is not clear what purpose is served by introducing
> sparsity.

There is, or was, and e-gold system, loom, in which
authority to obtain a certain amount of gold was
represented by urls containing a 128 bit unguessable
number.  When you deposited gold into the system, you
got a large random url, which enabled you to withdraw
gold from the system.  This seems like a capability
system to me.  What was the deficiency?  What makes it
not a capability system?

> > Thus the edit program does not need and should not
> > have a general ambient capability to open any file
> > it pleases...

> This is problematic. I agree with what you are trying
> to say from a security perspective. The problem is
> that *shells* really *do* require the ability to do
> that, and users have been trained into the belief that
> just about any application should be a shell. This is
> particularly apparent when one considers emacs, but as
> a second example consider the ubiquity of the File
> menu.

All file menus use *one* file chooser code that displays
a list of files  and allows the user to select it.  In
Windows and Linux all programs use the same file
chooser.  That is why Plash works.

I have identified three file access tasks that require
three file access powerboxes, and have not yet
identified any others.

1.  File selection dialog box:  Any program can invoke
this privileged code, which then pops up a dialog box,
displays a list of files that the calling program cannot
see, allows the user to select a file or files, and then
gives the calling program file handles with the
necessary privileges.

2.  Capability shell - by command line, user provides
access to particular files as part of a command to do
things to those particular files.

3.  File selection from project.  One of the project
files is akin is a make file, akin to a shell script.
This includes adding and removing files from the project
- which provides privileges for the script files that
build the project.

Script files and make files do not require powerbox
privileges, and thus the project "shell" in emacs does
not require powerbox privileges.  Rather, like any other
program, they have a set of files that belong to them,
which they can access freely without the user
specifically granting them access - the project make
file having read access to the project source files, and
read write access to the project temporary directory and
target files.

Thus when a normal edit program wants to read a file, it
invokes privileged code - which pops up user interface,
and eventually gives the calling program a file handle,
for a file that, in the case of plash, the calling
program could not know existed, let alone modify.

When a project is to be made, the program again invokes
privileged code, which pops up a user interface to build
a project.  When the user commands a project be built,
he interacts with a powerbox that gives the project
builder the file access authority to project files, as
indicated by the project file list.  So the project
builder program, such as "make", is not a powerbox.
Instead it gets its authority from a considerably
smaller and more privileged program that reads project
files.  We can, and should, have a single such powerbox
program for all sorts of project files, and all sorts of
project file builders - privileged code that guarantees
that only the user can define a project and what files
belong to the project, and that only project related
programs can access the files of the project, and can
only access the files of that project that the user has
currently selected and commanded to be built.