[cap-talk] Deep attenuation, typed operations

[Jed Donnelley]

----- Original Message -----
From: "Karp, Alan H" <alan.karp at hp.com>
Date: Friday, August 17, 2007 2:03 pm
Subject: RE: [cap-talk] Deep attenuation, typed operations
To: jed at nersc.gov, "General discussions concerning capability systems." <cap-talk at mail.eros-os.org>

> Jed wrote:
> > 
> > We could certainly start with that approach in an initial "CapDoc"
> > implementation.  One thing I like about that approach is that
> > it puts some amount of pressure on those implementing
> > objects to give comparable/compatible operations the same
> > name.  If that 'pressure' is adequate then perhaps nothing
> > like the more general typed mechanism for deep attenuation
> > will be needed.
> 
> Relying on the spelling of method names to enforce security sounds 
> like a disaster waiting to happen.  

You seem to be assuming something about the user interface.
This is indeed a difficult area.  Just consider all the mistakes that
happen in interpreting something as 'simple' as Unix rxws, chmod,
etc.

However, I can easily imagine user interfaces that can ease
this issue.  For example, suppose when one sets the
"deep attenuation" property on an object that it does
a recursive scan of the capabilities contained and
pulls out all the permissions.   Then it could present
you those permissions for selection from as to be
permitted through the "attenuation" (select from a list).

> I've been holding my tongue (keyboard?) on this thread, but I've been
> following it.  Deep attenuation is a reasonable policy to enforce 
> on a homogeneous set of objects, e.g, files containing references to files,
> but even adding directories makes it hard to understand what the
> policies mean. 

At least with directories in the Elephant system and in NLTSS
at LLNL I can relate that this 'deep attenuation" worked
exceedingly well.  Without such a mechanism it would have
been difficult to impossible to maintain shared directory
structures.  In the case of those systems the relevant
permissions were only read and write - rather simple
concepts - which were easily understood by the
scientists at LLNL (admittedly a somewhat scholarly
bunch).

> Any time a policy is hard to understand, policy is 
> hard to express and harder to verify that it does what you want.
> 
> That being said, deep attenuation is an important concept.  We just 
> need to find a way to express what we want it to do in a clear way.

I appreciate your weighing in on the topic Alan.

One possible simplification that occurs to me after thinking
about the above would be to limit the deeply attenuated
properties to read (anything that can return information
from the deep objects) and write (anything that can
modify the contents of an object).  This seems rather
gross, but simple and I think useful.  Of course for this
to work operations (permissions) on objects would have
to be so categorized.

This approach would seem to draw a line between
simplicity (e.g. only read write) on the one hand
and complete generality (typed permissions) on the
other.

Again I will note that I believe the most general
mechanism (typed permissions) can be used
to provide (present) a user interface for the
simplest mechanism, though of course the issue
of determining what constitutes a 'read' and
what a 'write' and what an 'other' operation doesn't
go away with the simplification of the UI.

Thanks again for commenting Alan.  Feel free
to make suggestions that you feel might make
this 'deep attenuation' mechanism less
confusing and more useful.

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