[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Fri, 2007-07-27 at 13:20 +1000, James A. Donald wrote:
> 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.

James:

As an editorial comment I have no objection to your statement above. As
a contribution to the ongoing conversation I found it disruptive. You
originally asserted that protected capabilities were not compellingly
useful anywhere. The two responses above by myself and David Wagner are
both responses to that statement. Your reply above appears to be a
complete change of topic. If you look at my text you will see that I
*do* use the word compelling. Your response does not address whether, in
your view, the powerbox is or is not compelling.

As a reader, I find this sort of context-free injection to be both
distracting and aggravating. In my opinion your response above
contributes only pedanticism. It completely disregards and fails to
respond to both my comment and David's -- exactly the complaint that you
raised before about others.

Do you have a response that is pertinent to the subject of discussion?

> David Wagner
>  > [...] powerboxes should grant transient capabilities.
> 
> Conversely, when the user issues a durable permission,
> he does not intend that permission to be communicated.

This is an unsubstantiated assertion about user intent. In the absence
of a comprehensive user study (and perhaps even after such a study), the
most you can safely say is that you *believe* this to be true.

I am not convinced that this is true. I am prepared to believe that it
is *sometimes* true, but I strongly suspect that the user's goals depend
on the situation. Can you articulate *why* you believe this is true?
When a user wants a durable capability to be non-communicable, what are
they trying to achieve?

> In practice, users do not want to issue durable
> permissions at all - the implications are inherently
> unclear.

In what way are the implications unclear? Why?

>   They are aware that they cannot do so safely.

Why not? There is some hidden assumption here that you are not
articulating. A useful response will begin with "The cannot do so safely
*because*..."

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

True, but how is this statement constructive in the context of the
present conversation? Does it shed some new insight, or is it just
gum-flapping?

> , so perhaps it is better to restate the
> problem in terms of user interface design goals:

Ah. This offers the hope of some productive response to follow. Good.

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

There is a huge set of assumptions in there that we need to exhume. In
your head, you have a picture of what you want the installer to do. The
rest of us are not in your head. Without a deeper description of your
installer it is difficult to imagine why a general script interpreter is
called for, and it is not really possible to comment on the merits or
issues with a design that you have not yet articulated.

In Coyotos, the installer is indeed "privileged", in the sense that it
has access to capabilities that are not generally available. It does not
have a general scripting language. It is closer in function to a linker:
the incoming "bundle" has a set of unfilled capability slots, and a set
of relocation entries describing these unresolved references. The
relocation table is a list of pairs of the form ("cap name as string",
slot-location). Finally, there is a capability identifying a process
within the bundle that is to be set running after resolution in order
for the application to self-initialize.

The installer maintains a number of contexts. Each context is an
environment defining a mapping from capability names to local
capabilities on the host. The relocation entries in the bundle are
resolved against this environment. If the resolution is incomplete,
installation fails.

The difference between a "privileged" application bundle and a
non-privileged application bundle is purely a matter of which
environment it resolves against. We haven't yet decided how this will be
selected. It may be based on cryptographic signing in some cases. I am
reluctant to resort to a dialog box, but that may be appropriate in some
cases.

Strictly speaking, the relocation mechanism that I have described here
is an execution of a script, but most people wouldn't think of this as a
scripting language. The need for a scripting language, in this design,
is subsumed by the ability to execute an initialization process that is
provided by the bundle itself.

Can you articulate what service the scripting language in your example
is providing?

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

In the Coyotos design we have no need for an uninstall script of this
form. We simply destroy the space bank from which the installed
application was instantiated, thereby reclaiming all of its storage.

The issue of configuration information is trickier than it looks.
Assume, for a moment, that we have a means to save this type of state. A
week from now, when the bundle is re-installed, how do we know to
associate it with this configuration information?

Worse, a week from now when a second bundle appears for installation, we
will want to "preserve" the configuration information by reading and
transforming the configuration information of the earlier version into
configuration information that is appropriate for the new version. How
do we know what configuration data to associate? The bundle in our hands
may be the next version of the app or it may not; the problem is that
the installer has no way to know that.

One solution may be to declare that all such configuration information
is publicly readable.

> Packages should be installed in a program directory that
> *only* the install script interpreter has general write
> access to.

On non-development machines this works OK. On development machines not
so good, because this forces the developer to use the installation
mechanism. It seems to me that the main purpose of guarding writes to
this namespace is to prevent the introduction of hostile programs. Why
should users be prevented from inserting "strictly confined" programs
into this space [I can think of several reasons; I'm trying to elicit
your rationale for the protective constraints you have given.]

Independent of the developer issue, there is a security problem here: we
are trusting the install bundle to provide the names that it will bind.
A bundle can install something on top of a name in that namespace that a
second bundle later requires (comparable to domain name squatting). I do
not know of any solution to this that is particularly satisfactory.

>   User cannot delete stuff, except by
> uninstalling, cannot modify stuff, cannot even browse
> the directory except by viewing the uninstall list.

There really isn't much of a reason to preclude introduction of strictly
confined subsystems. Deletion I agree; garbage collection is sufficient
(deletes names whose binding has been destroyed; proof of authority lies
in the fact that I was able to destroy the target of the binding). I
don't see any reason to preclude browse. Browse is essentially name
resolution. If names cannot be resolved by applications running on
behalf of users, the namespace has fairly limited value.

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

Write access here is potentially quite bad. The LAST thing I want is for
every instance of some program to share access to a mutable name space.
This is an invitation to trojan scripts! Backwards compatibility can be
carried too far :-) There is no real reason that these writes should not
be required to proceed through a powerbox.

The rest of your description starts into user interface design issues,
some of which I found interesting, but they started (in my mind) to
diverge from the discussion of the installation problem. I think they
are worth discussing, but let's get the stuff above sorted out and then
revisit them.

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

Reasonable people can debate the details of this, but no application
should ever have intrinsic unmediated access to shared writable
directories. Access to shared mutable namespaces should be held only by
the user's shell(s).

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

The powerbox part is fine -- in my mind the powerbox is an extension of
the shell. The application directories look like backwards compatibility
support for scripting viruses to me.

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

Meta: James: the parenthetical above is an example of a verbal attack.
Have you *used* Polaris? Have you seen its user interface? If not, on
what basis do you offer this unsubstantiated, strongly negative
judgment? If experience gives you a reason to believe that the Polaris
UI is horrid, you should be able to articulate why this is so. The
unsubstantiated value judgment made above leads readers to conclude that
you do not know anything at all about Polaris. When this type of
statement is made about many things, readers eventually cannot figure
out which of your opinions are substantiated and which are not. At some
threshold of recurrence (which is surprisingly, and perhaps regrettably
low) they conclude that most of your opinions are unsubstantiated, at
which point your credibility has been lost.

It is okay to ask for help sorting out your substantiation, but if you
cannot substantiate your opinion it is good practice to move your view
from the "opinion" category to the "presumed bullshit" category in your
head. It will help you write with greater consideration for how others
will read what you say.

Note: I do not take a position here on the Polaris UI. Perhaps it is
horrid, perhaps not. I have never seen it and so I have no opinion. My
purpose in this comment is to illustrate concretely one way in which
your style of writing is undermining your ability to write credibly.

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

Perhaps that description is natural to you, but it is not obviously
natural to me. To my eyes, your description is a set of conventions
about the names visible to the user rather than the names visible to the
application. There is no requirement that the user-visible namespace and
the application-visible namespace be the same. There is also no
requirement that the system as a whole have only one namespace. One fine
implementation of a per-application directory is a capability to a
directory object. In my private namespace, this capability is bound
under the name "Application Spaces/Foobar App". Within the foobar app,
it can simply be a capability having no name space binding at all.

Both implementations would work very well. There is nothing
intrinsically ACL-centric about the design you sketch. In some respects
the capability-based design might be better precisely because it does
not assume a singleton namespace. I concede here that the benefit of
multiple namespaces isn't intrinsically obvious one way or the other. I
think I can make a case for it, but whether that case is compelling
depends on other aspects of the protection model. The point I am trying
to make is simply that there are multiple natural implementations here,
and that the scenario is not intrinsically ACL-oriented.

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

Be cautious about natural language descriptions. They are very good when
things are simple, and they lead to bad mistakes when things are
complicated. It is better for things to be simple, but it is not always
possible. At best, a natural language description is a *model* of what
is going on. It does not follow that it is necessarily the best
*implementation* of what is going on.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC