[cap-talk] Declaring a victory - Delegation Bounds

[Valerio Bellizzomi]

On 11/08/2007, at 19.03, Jed Donnelley wrote:

>----- Original Message -----
>From: Mark Miller <erights at gmail.com>
>Date: Saturday, August 11, 2007 3:36 am
>Subject: [cap-talk] Declaring a victory
>To: "General discussions concerning capability systems."
><cap-talk at mail.eros-os.org>
>
>> Our Hotsec talk on Horton
>> <http://www.erights.org/elib/capability/horton/> went over like a lead
>> balloon. It's not that people didn't like it, it's just that people
>> mostly didn't care. We got very few questions and discussion. Perhaps
>> it's partially because we were the second talk so people weren't awake
>> yet.
>
>I'll mention a couple of other things regarding Horton discussions
>at the meeting.   While, as MarkM noted, there were no significant
>questions or interactions about Horton after our presentation,
>I (at least, I don't know about MarkM or others) became engaged
>in at least four or five discussions where the hooks that Horton
>provides for injecting policy when delegating authority from one
>identity (e.g. and especially a person) to another turned out to
>be the crucial mechanism to turn around some thinking to feel
>that capabilities might be the answer to their problem.
>
>In general these were all variations along the lines of the
>"loose" capability fear.   That is, people in many cases express
>concern that once a program has a capability it can share that
>capability 'anywhere' (i.e. loosely).  In particular with anyone.
>
>It surprised people and allayed some fears to hear that
>capability mechanisms can provide the abilities to:
>
>1.  Ask where a capability has been delegated, and
>2.  Revoke capabilities that have inappropriate
>     delegations
>
>as we have discussed with Horton on this list.
>
>However, I was surprised when a couple of additional
>possible uses for the Horton hooks (policy injection
>across id to id authority communication) came up:
>
>3.  Most surprising to me was the reemergence
>in a new (and to me more reasonable) form of the
>'pass once' mechanism for capabilities (e.g. as seen
>as an effort to combat communicating conspirators
>in a number of historical capability systems like
>Demos, Mach, and others).  In this context it becomes
>'delegate once' or as might be more meaningful
>at this "ID" level, 'don't re delegate'.
>
>As we well know, the "pass once" mechanism for
>'raw' capabilities makes no sense.  It blocks the
>development of finer grained implementations
>of services (introducing more objects) because
>the holder of the capability can't even communicate
>it to new "sub" objects.

If it is possible to do this with a counter inside a capability, it would
become 'delegate N times'.
And every time the capability is passed (delegated) we do:

	if (counter < N) {
	    counter := counter + 1;
	    <delegate_cap>
	}
	else {
	    <do_not_delegate_cap>
	}

the upper bound N controls dept of capability delegation, and can be
re-established for every service implementation.


>
>However, in the context of higher level identities
>(e.g. people) I believe a "do not re delegate" policy
>makes good sense and fits in as an effective
>additional potential policy in a suite of voluntary
>oblivious compliance policies (to use AlanK's
>term).  With such a "do not re delegate" policy
>(e.g. parameter to a Horton hook) in place,
>communication of capabilities can still be
>done within the responsibility of a single
>identity.  It's only when delegating to another
>identity (e.g. person) that the block takes effect.
>
>4.  Another place where the potential for a
>Horton hook provided value was what might
>be called "group" control (again VOC = Voluntary
>Oblivious Compliance).   Where this came
>up was in discussion about a situation where
>one might want to allow delegation between
>people within an organization, but put up a VOC
>block if an attempt was made to delegate
>outside the organization.  The Horton
>mechanism can be used for such control.
>
>It was very helpful to have the hooks for such
>policies available.  People were always
>surprised that such policies could be supported
>with capabilities.  In all cases it gave them a
>new perspective on capabilities and some
>indicated an interest in taking a new look at
>capabilities as a mechanism that might help
>them solve problems they were dealing with.
>
>The way I read these interactions is that now
>capabilities can be considered when traditionally
>ACL sorts of mechanisms are wanted.  E.g.
>who has access?  Remove access for this
>person.  Don't allow anybody else to access.
>Only allow access from within this group.
>
>This is a big change in people's thinking about
>capabilities.
>
>--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