[cap-talk] Deep attenuation, 'heritage', "allow-only" - operations as permissions

[Jed Donnelley]

----- Original Message -----
From: Charles Landau <clandau at macslab.com>
Date: Monday, August 13, 2007 7:38 pm
Subject: Re: [cap-talk] Deep attenuation
To: jed at nersc.gov, "General discussions concerning capability systems." <cap-talk at mail.eros-os.org>

> At 10:32 PM -0700 8/11/07, Jed Donnelley wrote:
> >Of course it must be noted that such a
> >mechanism in general requires a clear
> >definition of what the "permissions"
> >are.
> 
> Right. While you may think of the tree being composed of 
> directories 
> and files, it needs to be generalizable to any capabilities. In 
> general, permissions are specific to each class of capabilities.
> 
> Perhaps the semantics can be defined like this. If a directory has 
> the "deep attenuation" property, then when fetching a capability 
> from 
> it, the directory invokes the cap with a "deep attenuate" 
> operation, 
> passing its own restrictions, and returns the cap that that 
> operation 
> returns.
> 
> (You can see how to optimize this if the fetched capability is 
> known 
> to be a similar directory or other recognized object type.)
> 
> "Deep attenuate" would need to be an operation that can be applied 
> to 
> any cap, like the getType or SelfIdentify operation. And you would 
> want a convention for the bit assignment of common restrictions 
> such 
> as readOnly. (This bit assignment is relevant to the "deep 
> attenuate" 
> operation only, and is independent of the capability representation.)

Thanks for your comments Charlie.

I've only implemented such a mechanism for files and file-like
objects in NLTSS (files, directories, and processes) as the
"free access" permission following in the footsteps of the
"inheritance" mechanism from the Elephant system.

However, I've thought about this sort of mechanism a good
bit during and after our NLTSS work.  I describe below the
generalization I came to then but didn't implement.

Firstly here is another try at the name "allow-only" or
"permit-only" at add to my hopeful "heritage" suggestion.
I'm still entertaining names for this facility and asking
others to rate the possibilities so far.

In terms of the mechanism itself, what I suggest
(though I'm the first to admit that even this has some
awkwardnesses) is to assume that all allowed
operations on objects are named.  This is the
"foo" in b.foo(c) as in the Horton paper:

http://www.erights.org/download/horton/document.pdf

My thought for the "allow-only" property is that whenever
a capability is returned from such an object, an
"allow-only" call is done on the capability specifying
the list of permitted operations on the object through
which the capability is being returned.

With such a mechanism there still is an issue with
name coincidence.  However, for objects with this
property through which capabilities can be returned
(e.g. the documents in the CapDoc objects coming
up... - remember, think wideword with richer capabilities),
whenever an object is returned an "allow-only"
call is done to turn off all but the explicitly allowed
operations.  With this form I would expect that
objects supporting this property could support
more "permissions" than the object themselves
support.  For example, a directory object could
support the "allow-only" property and also
"permissions" for requests that it itself doesn't
actually support so that such operations can
be supported "deeply" (trying out again for
feel the "deep attenuation" phrase) for objects
even though the directory itself doesn't support
such operations.

A variation on this theme that I've considered is
one in which the permitted operations are
typed.  That is, each operation is listed with
a type, like [insert,directory] noting that the
"insert" operation will be explicitly allowed
when the "allow-only" operation is performed
on a returned object of type 'directory'.

This approach (for me) has the advantage of
eliminating possible conflicts in operation
names across types (whether intentional
and therefore possibly positive or perhaps
unintentional and in that case possibly
negative),while introducing the need for
agreed upon object type names.  With
this approach one could allow, for example,
[read,file] and [read-register,process]
but not perhaps [read,process] where
the 'read' operation on a process might
permit reading of the processes memory.

Bad example perhaps, but I hope you
get the idea.

Please let me know what you think about
either form of the "permit-only" or
"deep attenuation" property along with
the name - of course if you have time
to consider this feature which I am
planning for CapDoc.

Thanks!

--JED  http://www.nersc.gov/~jed/