[cap-talk] Concrete guidelines for user shell

[Jed Donnelley]

At 03:46 AM 6/29/2007, Pierre THIERRY wrote:
>I'm wanting to write a Web publication framework around a object
>capability core this summer, and have been prototyping a real estate
>management application in the end of 2006, where access control was also
>with object capabibilities.
>
>In both cases, I'm a bit confused about the best way to do the user
>shell. By user shell (an OS analogy, obviously), I mean the set of
>objects that ultimately hold all of the user's authority and constitute
>the interface between the user and the rest of the system.
>
>In particular, I was wondering if there are any best current practices
>or guidelines about authority communication between users.
>
>- is there a user directory where anyone can get a capability by which
>   he can send capabilities to the designated user?
>- is there any protection to avoid "spam"? (and DoS: if I send thousands
>   of useless capabilities to some users, how will they manage them?)
>- what kind of interface is used by the user to transfer authority, to
>   delegate it, to remember transfered authority and manage delegated
>   authority?

I believe the Wideword example is illustrative for this case:

https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D

Is there a YURL/Web calculus example that can be drawn on?

I'd be interested to know what people feel is needed in this
area beyond what Wideword provides.

Regarding:

At 08:21 AM 6/29/2007, Karp, Alan H wrote:
>Pierre THIERRY wrote:
> >
> > I'm also wondering wether users shells should by default be created
> > within a reference monitor to make it possible to enforce MLS-like
> > mandatory access control (that is, Alice has access to Secret
> > Folder and Bob, but cannot grant access for the former to the
> > latter).
>
>One reason to do this is to support Voluntary Oblivious Compliance,
>which goes beyond the simple security levels most people think of when
>they see the term "mandatory access control".  For example, Alice has
>access to a file that should only be shared with employees of her
>company.  In order to obey that policy, Alice would have to know that
>the policy applies to that file and whether or not Bob is an employee.
>A reference monitor can be used to enforce that policy without Alice
>being aware of it.  Work on Distributed Information Flow (Asbestos,
>Flume, Java Information Flow, Servlet Information Flow, ...) is also
>applicable.

Let's be careful to be clear about this situation.  I know Alan is
clear about it, but I hope we can avoid confusion in this situation.

The situation that Pierre describes, "Alice has access to Secret
Folder and Bob, but cannot grant access for the former to the latter"
is a statement of the communicating conspirators problem.  It isn't
possible in that situation for any "reference monitor" to block
the sort of access communication that is described.  As we well know,
Alice can proxy access to Secret Folder for Bob in that situation if
she wishes.  By attempting to block such delegation one can create
a horrific situation where proxying for delegation becomes the norm
simply because it is the only way to get the job done.

What I believe Alan is describing is a case (which I've never seen
work, but I believe he has) where all the parties involved agree
that certain capabilities should not be communicated between
certain parties (voluntary) and where they make use of a service
provided by their communication infrastructure to help them
implement this policy.

For any such implementation choice I believe it's important to avoid
the sort of horrific "get out of my way" situation that I note above
by insuring that any sort of blocking is easy to bypass with a simple
label change by the sender.  I strongly believe that you don't want
to force intended communication of a permission into a proxying
mechanism because the communication interface itself seems to
otherwise be blocking such an intended delegation.

One way to do something like this is to have otherwise ignored
"label" data included with the standard form of the capability
that can be viewed as communication to the "reference monitor"
(watch over me).  If the reference monitor blocks a delegation
because the sender, receiver and label seem to violate some
"Voluntary Oblivious Compliance" standard - fine.  Just make
sure that the sender (and receiver?) can decide that this really
isn't a 'voluntary' blocking and that they (mostly the sender)
can simply voluntarily change the label and go ahead and directly
delegate the desired permission without having to resort to
awkward and potentially costly mechanisms like proxying.

I generally feel it's best to avoid placing policies for
voluntary permission communication standards into a
globally and therefore relatively costly and potentially
unwanted shared infrastructure.  Of course it's always
possible to add such policies to a base implementation
without them, thereby allowing some to avoid their costs
while allowing others to make use of a potentially useful
voluntary service.  In fact, I suggest to all that being
able to add such voluntary monitoring to a base communication
infrastructure is a good test of just how 'voluntary' the
monitoring is.

--Jed  http://www.webstart.com/jed-signature.html