[cap-talk] what is a designation?

[Jed Donnelley]

At 08:58 AM 2/24/2009, John Carlson wrote:

>On Feb 24, 2009, at 3:01 AM, Toby Murray wrote:
>
> > On Tue, 2009-02-24 at 10:43 +0000, David-Sarah Hopwood wrote:
> >> Ben Laurie wrote:
> >>> On Tue, Feb 24, 2009 at 9:13 AM, John Carlson
> >>> <john.carlson3 at sbcglobal.net> wrote:
> >>>> Can someone explain what designation is when it comes to
> >>>> capabilities?
>
>This sounds like subjects designate.
>
>...
>I think this requires more explanation.

Here's my best shot on this topic:

Subjects do designate.  Subjects act on objects.  In order to
do so they must specify which object they wish to act on.
That specification (naming, choosing, etc.) is the "designation".

I believe we use the term "designation" much like the dictionary
definition:

1.  To indicate or specify; point out.
or
1.  To give a name to or describe.

When a subject (e.g. an executing program) wishes to act on
some object, it must select the object to act on.  It does
so by "designating" the object (file path name, process id,
socket number, etc.).

In a computer system some access control mechanism must
determine whether any subject (a running program) requesting
an action on an object is allowed (authorized) to carry out
the action on the object.

The unique aspect of a "capability" (very much a technical
term and not according to any dictionary definition) is
that it is a computerized "thing" that binds together:

1.  a designation (of an object) with

2.  an authority (permissions) to act on that object so that

3.  this binding can be communicated between subjects.

I (at least) consider anything with the above properties
to be a "capability" (e.g. see:  Managing Domains:
http://www.webstart.com/jed/papers/Managing-Domains/#s5 ),
independent of its implementation.

In typical modern day computer systems (e.g. Unix, Windows)
most designations (e.g. file path names, process ids, socket
ids, etc.) are not bound to an authority to act on them.
Any such authority is separate - e.g. associated with something
like a principal (user) identification that may be associated
with a subject (running program) that may ask to act on
an object by designating it.  Programs run as users, users
have authorities to act on objects.

The trouble with this approach is that when subjects
(in general mutually suspicious running programs,
"processes") want to communicate about objects, if
they communicate typical designations (e.g. a path name),
then a subject receiving a message has no idea
if the sender had any authority to act on the object.

This is the problem that capability communication
systems solve.

In a capability communication system if Alice sends
a message to Bob asking Bob to act on an object, Alice
must include a capability to the object in the message.
That capability both "designates" the object and
authorizes the subject possessing the capability
(Alice before the message is sent and Alice and
Bob after the message is sent - at least) to act
on the object (as specified by the capability).

In such capability communication systems it is
straight forward for mutually suspicious processes
(subjects, running programs) to coordinate actions
on objects.

In a capability communication system the Confused
Deputy problem (in the limited sense of:

http://en.wikipedia.org/wiki/Confused_deputy_problem

"The confused deputy problem occurs when the designation
of an object is passed from one [running] program to
another, and the associated permission changes unintentionally",
not in the more general sense of the Trojan Horse problem
or other sorts of code injection attacks)

can't arise.

--Jed  http://www.webstart.com/jed-signature.html