[cap-talk] Selling capabilities programming

[James A. Donald]

Jonathan S. Shapiro wrote:
 > 2. strict confinement: I know that the program has no
 > initial write
 >      authority to anything. In consequence, I am in
 >      full control of where it can send information.

Typically, we want the program to be able to write to
its own configuration directory - for example to save
the default state of tick boxes in dialogs, the default
position of windows, and so forth, and we want the user
to start the program by clicking on name that represents
start information, that grants the program various
permissions, among them permission to write to a
configuration file.  This startup information will be
set up by an installation script that the user did not
write, and is unlikely to ever look at.

In the case of suite installed by a single installation,
we likely want to grant permissions for members of the
suite to access each other, and supply information to
each other.

The bifrost approach to solving this problem is to
provide not very large set of named standard permission
sets, and the installation script has choose one and
only one of these standard ambient permission sets.  Any
non standard permission set has to be created by user
initiative, which is such a pain that the user is
unlikely to do it.

 > 3. TCB confinement: I know that the only write
 > authorities initially
 >      held by the program are to "trusted subsystems".
 >      For example, the program may have access to a
 >      known directory instance. The directory instance
 >      is not confined, but it executes trusted code,
 >      and I happen to know that this directory instance
 >      contains (by construction) only capabilities to
 >      constructors of confined subsystems.

This may be equivalent to the case I describe above, or
it may not.  It is not clear to me, and is unlikely to
be altogether clear to the user.