[cap-talk] 'Mask' (sensory, inheritance, Norm)

[Jed Donnelley]

cap-talk,

I'm reaching out for help refining and naming a mechanism
that has been around in capability systems for some time.
I feel the need for this mechanism in this system that I'm
referring to as "CapDoc" (think of it as an extension to
the existing Wideword facility if you like, based on
Waterken with Horton injected identity hooks, etc.).

In the old Livermore Elephant system this mechanism
was called "inheritance" (before that term was adopted
for OO).  In the NLTSS system we flipped the sense of
it and referred to it as "free access".  MarkM indicated
that something similar was used in KeyKOS I believe
referred to as "sensory" (?).

The basic idea is to have a mechanism for
"attenuating" (reducing permissions conveyed
by) capabilities fetched through other capabilities.
When we were thinking of names in Boston MarkM
came up with "deep attenuation".  In thinking about
it now I think I like the term "Mask" (for reasons
explained below) for this property of a capability.

I think the idea is easiest to explain using the
concept of a directory - namely an object that
contains a list of named capabilities.

One can imagine read or read/write access to
such a directory.  One can also easily imagine
capabilities in such a directory including some
that are themselves directories that may be
read-only or read/write.  Also there may be
files in any such directory structure that may
be read-only or read/write.

One might have a deep structure of this sort
and have the desire to share it.  Of course sharing
the whole thing is easily accomplished by
sharing a read/write capability to the root
of the directory structure (not necessarily
a tree of course).

However, suppose you wish to only permit
reading of directories and files in such a
structure.  It seems that you have something
of a dilemma.  You can of course turn off
write permission to the top level directory
before sharing it, but what about the objects
in that top level directory?  When they are
fetched (read?) they are nominally read out
with whatever permissions are encoded in
the capability - e.g. including write access to
the contained files and/or directories.  This
dilemma goes all the way down.

You can of course imagine constructing a
whole "mirror" directory structure composed
of the equivalent read-only instances of all
the objects in the directory "tree".  That would
be painful - even if somehow automated.
It could also require a combinatorially large
numbe of such structures.

Enter ... Mask (deep attenuation, sensory,
inheritance, free access ...).   With "Mask"
I assume that the default behavior of a
directory object is to allow any permissions
that show up in the directory through as they are
being fetched.  If you think of permissions
as naming operations that can be performed
on objects (e.g. read, write, insert, destroy,
list, append, invert, send, etc., etc., etc.) then
you can imagine a directory service with these
properties:

1.  If the directory has the "Mask" property
then only permissions in the directory capability
are left enabled in the capability fetched
through the directory.

2.  If the directory doesn't have the "Mask" property
then capabilities are fetched unattenuated
(at least with no permissions turned off - they
may, for example, still have their responsibility
label changed as per Horton which could be
considered an "attenuation").  That is, all
permissions that were allowed in the capability
in the directory are still on in the capability fetched
from the directory.


In the case of my rich directory example above,
if "Mask" is a property of the top level
directory, then any permission not in that
top level directory will be turned off in the
capabilities fetched through that top level
directory.

This sort of mechanism can (and did at LLNL
in both the Elephant system and in NLTSS)
help with the sharing of a 'deep'ly
attenuated access to such a structure.
If the "Free access" bit was turned off
in an NLTSS directory or if the "inheritance"
bit was turned on in an Elephant directory and
either read or write was turned off, then
all objects fetched through that top level
directory, to whatever level, would have
their corresponding access turned off
as fetched.

One simple thing to note about the "Mask"
property is that it isn't really a permission.
That is, I don't imagine any sort of a "Mask"
operation on objects such as directories.
Rather the "Mask" property effects the
way other operations are carried out (in
particular read or fetch).

It's because of this difference between
a property and a stricter permission that
I don't feel compelled to flip the sense
of this property as we did in NLTSS.
Perhaps this was MarkM's unstated
argument why this property could be
called "deep attenuation" and act as
what I'm calling "Mask".

One other thing to note about this
property is that it can provide a
motivation for additional "permissions"
for directories (or anything that capabilities
are fetched through).  In this form as
"Mask" or "Deep attenuation" the
mechanism is 'fail safe' in that un
stated permissions are turned off.
Because of this and the possible desire
to allow permissions through (un
'Mask'ed or attenuated), there may
be a desire (need, requirement) to
allow additional permissions for
the directory objects that aren't
meaningful as permissions for the
directory objects themselves (e.g.
a "send" permission).

Of course it must be noted that such a
mechanism in general requires a clear
definition of what the "permissions"
are.

Finally, notice the odd importance of
coincident names for operations with
this mechanism.  If the operation of
inserting a capability into a directory
by name is referred to as "write"ing
the directory, then by simply turning
off the "write" permission to the top
level directory and turning on the
"Mask" property one can protect
both files and directories from
modification by write operations
throughout a directory structure.
Might it be that it is only this case of
read and write permissions for files
and directories where such a "Mask"
mechanism makes sense?

My questions to the list are:

A.  Does anybody know of a write-up of
such a mechanism on the Web.  I imagine
I could find documentation on the LLNL
mechanisms if anybody is interested.

B.  What do people think about such a
mechanism?  Is something like it needed
at all?  If not, then how would you achieve
the value noted above for parsimonously
sharing a whole directory structure with
different authority?  If so perhaps you feel
that it can be done more effectively than
suggested above?

C.  If you do feel that a mechanism like the
above provides worthwhile value, what name
would you give it?   "Mask", "Deep attenuation",
"Sensory", "Free access" (reversed sense),
... what?

Thanks for any time you might have to consider
this topic.  I'd like to get some sort of a concensus
on this topic before describing it as part of the
CapDoc service.

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