[cap-talk] Objects and Facets

[David Hopwood]

Jed at Webstart wrote:
> Terminology,
> 
> I have to admit that don't follow some of the nuances of this discussion.
> For me what it comes down to is:
> 
> At 07:02 PM 8/6/2006, Charles Landau wrote:
> 
>>...
>>The only formal reality is capabilities and processes.
> 
> capability = reference

This defines nothing. What is a "reference"?

(My answer is that it is a first-class value that unambiguously designates
a single object, for the lifetime of that object.)

> process = active object in a "domain" (is a domain?)

Capability systems differ significantly in their concurrency models
(some are only sequential). They also differ in the granularity of
protection domains. So if we want to include "domain" or "process"
in the common terminology used to describe cap systems, we must be
careful not to overspecify the relations between degrees of activity,
protection domains, and objects.

For example, in E protection domains coincide with object boundaries,
but the unit of concurrent activity (a vat) is larger. In KeyKOS and
EROS, threads migrate between protection domains, and each protection
domain may implement multiple facets/objects. In actor systems,
protection domains coincide with object boundaries and all objects
are active. There are other models that would be as reasonable as these.

> object = whatever a capability/reference permits access to

This is not sufficiently precise. Is the access dependent on context?
Is it time-varying? Can a capability/reference permit access to more
than one invokable interface? What is the relation between "objects" in
capability system terminology and "objects" in access control terminology?

> This:
> 
> At 05:19 AM 8/7/2006, David Hopwood wrote:
> 
>>...there are two capability systems, a local one and
>>a distributed one. In the local system, there is a socket object; in
>>the distributed system, there is a remote object. The socket object
>>is part of the implementation of the remote object in the distributed
>>system.
> 
> sounds reasonable to me.  I think it important to use the terms
> "capability" and "process" (active object) for the highest level of
> abstraction - allowing multiple implementation and possible
> translations.
> 
> Regarding a list like David supplied (below with comments), I'm
> not sure what value such a list provides except perhaps for
> guidelines/examples.  To me any attempt at formalism through
> such a list is unwisely constraining.  I hope my comments
> will suggest why I feel this way:
> 
> At 05:19 AM 8/7/2006, David Hopwood wrote:
> 
>>Each object capability system defines what it considers to be an object,
>>and what it considers to be a capability, subject to the following
>>constraints:
>>
>>1. a capability unambiguously designates a single object;
> 
> I don't understand what the above contributes.  How could it
> be otherwise?

Of course it could be otherwise. I am trying here to specify what
the roles of "capability" and "object" are in a capability system,
*without* assuming prior definitions.

[...]
>>2. objects may hold capabilities to other objects;
> 
> Again I don't see the value.  Certainly active objects (processes)
> may hold capabilities (to other objects - again redundant), but
> what does the above add of value?

Not just active objects; any object may hold a capability.

(A primitive tuple object, for example, is not active in many capability
systems.)

>>3. in general, an object may have mutable state;
> 
> This needs to be stated?

Yes! Even if we take for granted that a capability system is a
computational system, if this is not stated then it might be a purely
functional system, or mutable state might reside in some other kind(s)
of entity than objects.

>>4. an object may be invoked by another object having a capability to it,
>>   and not otherwise;
> 
> This one above seems to me the essence of what a capability is.
> A capability is a token granting a permission.  Since it does so
> there must be some means to yield that permission - an "invocation".

It is not obvious that permissions are exercised (only) by invoking
discrete operations, each of which sends a message to a single target
object.

> Unsaid here but I think implied (certainly desired for confinement) is
> the notion that no permissions outside a process are available except
> through capabilities.

That is not characteristic of all capability systems. Not all cap systems
are able to enforce confinement. Also, in some systems there are resources
that are considered "harmless" or outside the scope of protection by
capabilities (such as processor time and memory in E, but not in KeyKOS).

>>5. invoking an object causes it to act on a message specified by the
>>   invoker. The invoker may specify capabilities it holds that are
>>   transferred with this message to the invokee;
> 
> Of course the invocation, being the means for yielding the permission,
> must allow some action to take place.  Considering that in the context
> of a "message" seems reasonable to me.
> 
> The important aspect of this #5 seems to me to be the idea that
> permissions as "capabilities" can be delegated through an invocation,
> communicated.  Combine #4 and #5 and it seems to me you have the
> essence of the object capability model.

With #4 and #5 alone, we would be using undefined terms and making
unwarranted assumptions.

Your objections to #1, #2 and #3 seem not to be that they are untrue;
only that they are too obvious. I don't think they are obvious, because
there are many other means of organising computation and/or access
control, or other ways in which "capabilities" and "objects" could be
related.

>>6. an object may create a new object X with a specified behaviour and
>>   initial state, optionally transferring capabilities it holds to X,
>>   and obtaining a capability to X;
> 
> The above need not be true and to my thinking adds an unnecessary
> constraint.  It need not be true because it is only by way of some other
> capability the permission to create a new object is conveyed.  An
> object (process) without such a capability won't be able to create a new
> object as above.

That's a good point. The ability to create objects is not necessarily
primitive (although it is primitive in some cap systems). I will think
about how to fix #6.

>>7. in a running system, the only ways for an object to obtain additional
>>   capabilities are as specified in points 5 and 6.
>>
>>Password capability systems, where each capability is represented by a
>>password, satisfy a weaker version of point 7:
>>
>>7'. in a running system, an object may only obtain additional capabilities
>>    by gaining knowledge of their passwords, and *the system* only transfers
>>    passwords according to points 5 and 6.
> 
> I view as counterproductive efforts to define a dichotomy between
> implementations of capabilities, some as protected references and some
> as data, including but not limited to "password" capabilities.

Password/sparse capability systems are indeed fundamentally weaker in
the security properties they can enforce. I see no advantage in sweeping
this under the carpet.

[...]
> I believe those working in the capability communication field most
> often start creating problems if/when they start to think that they
> can do things with their implementation that aren't possible in
> general - such as blocking delegation between cooperating
> conspirators as we've discussed recently on this list.

Authority confinement is only impossible in an open network.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>