[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Mon, 2007-07-16 at 06:44 +1000, James A. Donald wrote:
> 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.

James:

You have a lot of value to add. Many people here, including myself, have
found your contributions and thoughts interesting and helpful. Lately,
however, you have indulged in outbursts that do you no credit. I suggest
that when you find you cannot write politely, you should wait until you
can.

Consider your response above. There are three problems:

1. It is off-topic. Please explain the relationship, if any, between
your (erroneous) understanding of Xanadu and the subject at hand, which
is defining the term "protected capability system"?

2. It is false to the exchange at hand. You disregard my comment that
the cryptographic scheme you sketched was appropriate for the e-gold
problem, but is not appropriate for a general capability infrastructure.

3. It is a vicious, personal attack. You know perfectly well that
several participants here worked on Xanadu. Perhaps you like to hurt
people. I cannot think of another reason for this behavior.


If you want to make this conversation productive, you would do better to
ask *why* the distinction between protected and unprotected capabilities
matters.

The problem with unprotected capability systems is that they cannot
enforce authorities of *any* sort. That is a statement of mathematical
fact, supported by multiple formal works. It is also a statement of
empirical observation, since systems of the type you describe have
consistently failed to enforce policy successfully for reasons that are
axiomatic to their design.

Now, if you wish to have a productive exchange, try asking why this is
so and I will try to answer you. I'll even promise not to point you at a
bunch of theory papers. :-)

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

Actually, it is *exactly* this context in which it is useful, because
restricting permission propagation is the essence of the power box
design that you advocate. The power box approach is founded on authority
confinement, and cryptographic capabilities cannot be confined.

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

I think this is basically correct, but it is orthogonal to the need for
confinement.

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