[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Mon, 2007-07-16 at 01:20 +0100, David Hopwood wrote:
> I only know of one capability language *proposal* that used
> non-protected caps (Safe Erlang, which was never fully implemented).
> All other cap languages enforce that references are opaque, i.e.
> that they are protected capabilities.

Strictly speaking, opacity is not a requirement. What is required is
that there must not be any operation accepting data and returning a
capability from that data.

Opacity is desired for many reasons, but it is not a requirement for
safety.

And strictly speaking, my statement of requirement is still too strong.
It is actually okay to convert user data into a capability that performs
read-only access on pure-constant state, provided the pure-constant
state is a deterministic function of the input user data. This explains
why KeyKOS number capabilities are safe.

> I'll leave others to discuss the implementation complexity of
> password vs protected caps in the OS case (my impression is that
> there isn't much difference, and that this is not a significant
> reason for any delay in deploying operating systems using protected
> caps).

I don't think that there is any significant difference. In effect, the
password caps aren't capabilities until the application authenticates
them. At that point, the system caches a protected cap within the
per-domain state held by the supervisor.

The main issue from a security standpoint is that either (a) confinement
now needs to be considered dynamically or (b) a mechanism preventing
further capability authentications must exist so that the results of a
static pre-check remain valid.

> Note that using protected caps on each local system in no way
> compromises the ability to extend the system over an open network.
> Components that are so extended cannot be confined, but that isn't
> usually a problem. The techniques needed to implement this are
> well-known, and have been applied to both capability operating systems
> (e.g. NTLSS) and languages (e.g. E).

If the runtimes on the two ends are mutually trusting, the components
can still be confined.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC