[cap-talk] capabilities as channels and as communication protocols

[David Barbour]

On Mon, Mar 2, 2009 at 9:23 PM, James A. Donald <jamesd at echeque.com> wrote:

> Do people think that this description of capabilities makes sense?  I
> solicit criticism.
>

I'll admit to being critical of the 'object-capability system' bias. To me,
a capability is any tight coupling of authority and ability that can be
granted, delegated, or transferred independently (that is, without also
needing to grant, transfer, or delegate a larger authority or ability). SPKI
capabilities and other password capability systems can, and should, qualify
as capabilities. They are of particular interest to "offline" designs,
rights escalation, and exclusive transfer.

Where you use 'capability', I'd use 'object capability'. They have the
advantage of being very efficient, and a disadvantage of being weak against
network disruption (when dealing with distributed object caps).


>
> A capability is an object, object in the sense of "object oriented
> language", that combines unforgeable designation with permission - it is
> an object that enables an entity to do something, to do something to or
> with a very specific thing, the thing designated.
>

What does 'unforgeable' mean? If I can guess at 160-bit numbers and
eventually obtain a capability in a distributed system, was that
'unforgeable' or just 'difficult to forge'? To me, 'unforgeable' means
'impossible to forge', which physically cannot apply to delegable and
transferable capabilities in a distributed system. All we can do is make
forgery arbitrarily, and cryptographically, difficult - and then mount a
more active defense to detect likely forgeries.

And regarding "object" and reference to "object oriented language" - that's
poorly defined. You'd need to eliminate issues of, say, examining references
to the caller or the call-stack as is performed in Common Lisp for its
condition-reset mechanism. You'll also face issues that in most object
languages, you have capabilities to do stuff even without object refs.
You'll further face issues that many OO languages lack any sort of
protection against viewing their guts, such that they cannot grant
capability to JUST do a specific thing - they grant the whole gamut of
implementation.

And then there is "enables". You could create an unforgeable reference to an
object that opens a file... but if that capability is part of the
environment ('ambient'), then anyone to whom you passed the object isn't
getting any new capabilities... they're just getting a helper object.

Besides, you should define 'capability' first, then explain why 'objects'
can (under certain constraints) be such fine examples of them. That would
help eliminate the object-capability bias, and force you to reduce
conceptual dependency on ill-defined concepts.


>
> But since a capability grants permission it in practice is also a
> communications channel, or the ability to open a communications channel,
> between two entities - thus for example a file handle is a
> communications channel between some program, and the highly privileged
> operating system software that has block level read/write access to the
> disk.
>

That does not seem to follow. Since when does permission "in practice" also
determine ability? If you had permission from Mr. Obama to fly me to the
moon (and let me dance among the stars... though I'd prefer to avoid
metaphor) could you do so?

No, capability *grants ability*. That's the reason it includes a
communications channel or the ability to open one. Ability isn't a feature
of permission. Ability AND 'permission' are both features of capability. If
you grant one decoupled from granting the other, you did not grant a
capability. Granting ability without authority is just dangerous, since then
you need to control use of the ability by other mechanisms (usually 'trust'
and more active detection + rectification). Granting authority without
ability is often futile, though it does work at times as an element of
rights escalation.

Anyhow, that's my criticism. I'm reluctant to mention it to a forum that is
so object-capability biased and that doesn't bother rectifying
distributed-system capabilities with misleading phrases like 'unforgeable'
despite the clear examples in Pluribus. Last time I said even suggested that
capability might allow for more than object capability, I received confusion
from many and attacks from a subset of that many. I doubt expressing my
opinion is worth that trouble, but I'll take that risk this one more time.

Dave

-- 
hubris and humility compose
perfectionism, paralysis, a curse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090903/d4e9152e/attachment.html