[cap-talk] Selling capabilities programming
Jonathan S. Shapiro
shap at eros-os.com
Mon Jul 16 13:34:04 EDT 2007
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
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
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.
The EROS Group, LLC
More information about the cap-talk