[cap-talk] Terminology and soap box (was: Objects and Facets)

[Jed Donnelley]

All,

Check out the last paragraph and see if it might help motivate
the discussion that leads up to it.

At 07:36 AM 8/8/2006, David Hopwood wrote:
>Jed at Webstart wrote:
> > Terminology,
> >
> > I have to admit that I don't follow some of the nuances of this discussion.
> > For me what it comes down to is:

<capabilities are communicable units of permission>
<one can define an "object" as that to which the permission is granted>
<everything else is derived - as in the discussion below>

or as Charlie wrote:

> > At 07:02 PM 8/6/2006, Charles Landau wrote:
> >>The only formal reality is capabilities and processes.

The above is where I'm coming from, though at a cross system
network level.  You will see the above reflected in the whole
discussion below.

> > capability = reference
>
>This defines nothing. What is a "reference"?

I'm not trying to define it with the above.  I'm only pointing out that for me
the terms are synonymous.  Just as are 'process' and 'active object'.
I defined what a capability is above (a communicable unit of permission).
I really don't think anything more is needed, but I'll follow along with your
approach and try to make it work - below.

I'm trying to abstract these terms so that they are applicable to a wide
variety of systems.  I argue that it's at the network where things come
together, standards must interoperate, and the terminology becomes
most meaningful.

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

You must realize that the above is no better.  It just ties in yet another
term, "object".  Does the object define the capability (permission) or
the capability the object?  Of course the answer is neither.  They are
only related in that one is the communicable token granting a permission
and the other is the abstraction of what the permission grants.

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

In the above I'm just trying to tie together terms that for me
have no relevant distinctions.  A "process" and an "active object"
are both essentially environments (virtual processors in a weak
sense) that programs can run in.  They constitute a "domain"
in that somehow the system limits their authority (their permissions).
For me their "domain" is another name for their "authority", the
recursive sum of their permissions.  If we want to restrict the use
of one term or another, I can live with that.  However,  I need a term
that I can use as an abstraction across systems.  What will that
term be?  Whatever it is, how are the alternatives relegated to
lesser (more restrictive - or one might more positively consider them
better defined) roles?

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

Certainly.  This is why for me the network is the most important
part of the "capability" abstraction.  If one considers a "client"
and a "server" on distinct systems on opposite sides of a network,
but where the client has some permission granted by a communicable
token of permission (received somehow), and the client is "invoking"
that permission (capability), then notions like the concurrency model
(on one side it can be synchronous/sequential and on the other
non blocking/parallel) or even really most aspects of the access control
model (on one side it could be a DVH-like protected reference, c-list
model and on the other an Amoeba or Monash or YURL password
capability model) aren't relevant to this level of model.  All that's
important is that we can agree on the highest level of terminology
(processes [active objects], capabilities as communicable permission
tokens, and whatever capabilities grant permissions to - "objects").

I believe we need standards for communicating such permissions that can
span systems and networks.  However, I think it also important that at
least our terminology span systems and networks.

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

Yes, there are many others.  What happens when the capabilities
from systems like the above get communicated to other systems
that use different models?  Whatever THAT is that gets communicated,
THAT's a capability.  Whatever it grants access to, THAT is an
object.  I believe we need to get beyond what I see as a sort of
bickering about details of systems to a higher level generic notion
of "capability" and "object" that can be used between systems
across a network.  For me the network abstraction needs to
force the model on the local systems.  I believe we need a global
"capability"/"object" economy, not a bunch of fiefdoms.

> > object = whatever a capability/reference permits access to
>
>This is not sufficiently precise. Is the access dependent on context?

Can be.  Certainly on the server's context.  Not I think on the clients -
remember the network model.  The server in general has no way
of knowing anything about the client's context.

>Is it time-varying?

Can be.  What's the problem?  Consider a clock server.  Send it
a "what time is it?" request and it returns you a clock value.  Certainly
time varying.  Send it a "reply at this time" request and it waits until the
time and then replies.  Also time varying.  What's the problem?  These
sorts of services certainly fit in my model of "process", "capability",
and "object".

>Can a capability/reference permit access to more
>than one invokable interface?

No.  The capability is the unit of invokable interface.  By definition.

>What is the relation between "objects" in
>capability system terminology and "objects" in access control terminology?

"object"s are simply an abstraction of whatever it is that the
permission granted by a capability grants access to.  E.g. in the
above example a "clock", a file, a process, a port, a vote, a directory,
really anything.  Anything that one can imagine granting a permission
to do - where a permission token (the capability) is "invoked" on one
side of the network, something magical happens (messages fly,
standards and translations are processed, etc., etc.) and then
something happens and a result may be returned - the abstraction
of whatever happened, that is the "object" on the other end.

Perhaps you disagree with my approach, but I'd at least like to make
clear where I'm coming from.  If people disagree I'd like to understand
why and what they see as the desirable consequences of more
limited, systems specific notions that can't be networked together
or even really considered together with a common set of terminology.
In my book "capabilities" admit different implementations with different
properties.  I hope to make them interoperable and I want to at least be
able to use common language to discuss them in the mean time.
...
> >>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.

I hope the discussion above clarified where I'm coming from.
As you can see, for me the "object" is whatever the capability
grants permission to access.  Perhaps we are just agreeing
violently, but to me having so many requirements that appear
to me to be redundant makes the "capability" model seem overly
complex and formal and restrictive to no positive end.

>[...]
> >>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.)

Are you trying to say that capabilities can be "stored" in
non active objects?  Certainly no non active object can
"invoke" a capability - by my understanding of the definition
of "active".  If we agree that capabilities can be communicated
between active objects (processes), then it's a consequence
that "non active" objects (which are, after all, implemented by
active objects/processes) can store such capabilities and
give the impression of having them stored in inactive objects.
I still don't see what this adds.

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

Some systems may indeed be purely functional.  Are you trying to suggest
that their capabilities aren't good enough for others?  I'm perfectly happy
to work with capabilities to functional and to nonfunctional systems.
I'm a network kind of guy.  I'll take any capabilities I can get and use
them in any way that makes sense.  Developers of individual systems
may be functional or not, synchronous or not, support confinement
or not, etc.  As long as they play the standard "capability" game
then I can work with them.  I may only trust them to a limited extent,
but their capabilities can be communicated and included in the
network economy.

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

Fine.  Let this one stand then as the part of the definition of a capability
that says 'a capability is a permission granting token'.  Now we just need
the communicability requirement (below).

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

Right.  Sorry.  My bad.  For a second there we flipped sides.

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

What #5 seems to add for me is the communicability (delegation)
requirement.  Capabilities are communicable tokens of permission,
nothing more and nothing less in my book.  What about yours?

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

All terms are defined in terms of others, including common dictionary
definitions.  Your set of seven of course also leave many terms undefined.

>Your objections to #1, #2 and #3 seem not to be that they are untrue;
>only that they are too obvious.

Not just obvious, but that they follow from #4 and #5.  At least that if
they don't, then they are overly restrictive.  If #1, #2, and #3 say more
than that capabilities are communicable units of permission (as I believe
#4 and #5 say - perhaps not as I would say it), then what?  Whatever that
is, I'm afraid I consider it overly restrictive.

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

Perhaps you can give an example so we can see how #4 and #5 can
be met but the others not.  To me saying that "a 'capability' is a
communicable unit of permission" says it all.  Perhaps that can be
made more concrete for some in a set of requirements like your
effort.  For me, however, this set of 7 seems overly restrictive
and unnecessarily complex.

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

Hey, a point of agreement.  Progress - even if we don't come to a
final consensus on the big picture model level argument that I'm raising,
at least we made some progress within your model.

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

We disagree.  Here is my argument (along the lines of the conspiring
communicators argument):

Can a non password capability system create password capabilities?
Of course it can.  It can communicate data and it can create services
to manage such data as "capabilities".  Perhaps not the protected
reference sorts of CAPABILITIES defined by the system and somehow
hoped for as the only sort of capabilities, but such password capabilities
can be created and communicated - wherever communication is possible
(perhaps only through the non password sorts of capabilities).

You might argue that such created password capabilities aren't
"real" capabilities in the "system".  If not, why not?  What happens
when active objects in The "system" receive Amoeba capabilities
or YURLs?  Are they capabilities?  If not, what terminology do we
use for them?  If they are capabilities, then how is the "non password"
capability system any stronger?  It isn't.  It isn't any more than
DEMOS (or systems like it) were stronger by including a "do not
delegate" bits in their capabilities (DEMOS called them "Ports").

<Baskett, F,, J. H. Howard, and J. T. Montague,
"Task Communication in Demos,"
in Proc. of the Sixth Symposium on Operating System Principles,
Purdue University, November 16-18, 1977 (in ACM Operating Systems
Review 11(5), 1977), pp. 23-31.>

Such an approach can force proxying for delegation, but it can't
stop delegation.  Similarly any effort to block "password capabilities"
to strengthen a system is an illusion, forcing awkward new constructs
for what may be needed forms of communication.

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

It isn't possible when any sort of non capability granted communication
is possible.

OK, here's my soap box appeal:

Join me my brothers!  Capability systems of the world, Unite!!
Together we can redefine the world in our image!  Together we
can lead the world out of confused separations of designation
and authorization to a better world of POLA!   Let us join together
in a common alliance across all systems, across all networks!
Let us join with our capability brethren in network standards
to spread capabilities to the darkest and most confused
non-POLA corners of our computing universe!  Let us bind
together designation and authorization and insure that there will
never again be failed and confused efforts to block delegation
of permission across communication channels!  Together we
can do it.  United we stand, divided we fall!

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060808/39784db6/attachment-0001.html