[cap-talk] Selling capabilities programming

[James A. Donald]

Jonathan S. Shapiro:
 > The problem is that this authority can be overtly
 > transferred over a channel that is not authorized by a
 > capability. Because of this, there is no possibility
 > of restricting the propagation of permissions.

Seems to me that capabilities programming is suffering
from the same ailment as the Xanadu system suffered -
that the ideal imagined capability system is getting
further and further from being written.  Towards the
end, Xanadu as imagined, was not merely code, but rather
required as a precondition for its existence a profound
social transformation.  They spent decades refining the
concept of Xanadu, in the process removing it ever
further from reality, rather than providing useful
software embodying and utilizing that concept.

In the context that we are defending the users from
malware, rather than management from users, restricting
the propagation of permissions strikes me as bloody
useless.

The more easily capabilities can be passed around, the
finer we are apt to slice them.  The finer we can slice
them, the less gratuitous authority we give
applications.  Only some rather special capabilities
need special treatment, and those capabilities are not
critical to the major problems we face today.

The meme we need to fix the malware crisis is "combine
designation with permission"  It looks to me that
protected capabilities significantly complicate this
solution, particularly in a potentially networked
environment such as X windows, which may well be why you
see difficulties with solution of prohibiting almost all
programs from accessing almost all files, or even
discovering they exist, while I see no such problems.

1.  The file select box that comes up on the file menu
of all programs is in fact, in existing operating
systems, on piece of code, the same code for all
programs.  That one, not very large piece of code,
should be special privileged code, one of very few such
pieces that is privileged to enumerate files in
directories, and provide file handles giving read or
write handles to those files.  The standard "open"
dialog and "save" dialog should represent the program
invoking a powerbox which both designates the file and
gives the program the capability to access the file.

2.  Similarly for the command line interpreters.  Again,
in practice we have a very small number of command line
interpreters, which is not quite as favorable as the
existing situation for file menus (one single file
select dialog box), but is close.

3.  Similarly, there should core piece of privileged
code for all programs that group files into projects,
and build files from other files.  A make file should be
invoked through a project file, and should only have
access to the files listed in the project file.  The
project file manager should be responsible for the user
interface enabling the user to add or remove files from
a project, the user interface that selects a file for
editing from the project and grants the calling program
capability to edit that file, and the user interface
that launches a build and grants the build program
capability to access the files in the project.  In
Microsoft systems at present, there is no one core
project file manager, but you will notice substantial
commonality in the format of project files, and in the
user interface for file selection among project files,
indicating that the diverse people writing diverse
project managers have extensively used common code at
the source code levels, since at the level of grouping
files for editing and building, all project managers do
the same thing.  Since they all do the same thing, they
can all be replaced by one project file manager, invoked
by a multitude of different editing and building
platforms, though revising existing project oriented
software such as emacs to use a single project file
manager is likely to be a lot more work than merely
plugging in a powerbox in the file menu.