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

[Sandro Magi]

As the Waterken server has shown, revocable delegation of a page must be
a operation that can be performed to the page. The wrapped version sent
transitively wraps every capability reachable from the page.

Sandro

John Carlson wrote:
> Also imagine what you are trying to do when your capabilities
> are perhaps embedded within web pages.  How do you share the
> web pages without giving everyone your CapDoc capabilities?
> 
> I think the suggestion that was offered when I brought this
> issue up was 2 factor capabilities.  You could see the
> links on the page, but if you didn't have the second set
> of capabilities found in an index, you couldn't do anything
> with the links.
> 
> Thus you could share your web pages without the index,
> or just turn on the index items that you wanted to share
> with someone.  I don't know how to 'Mask' the index.  I was
> imagining it could be fairly flat, and shared as needed.
> 
> Is this still 'Mask' or am I thinking of something else?
> 
> 
> John
> On Aug 11, 2007, at 10:32 PM, Jed Donnelley wrote:
> 
>> 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/
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk