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

[John Carlson]

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