[cap-talk] Declaring a victory - Delegation Bounds

[Valerio Bellizzomi]

On 12/08/2007, at 6.23, Jed Donnelley wrote:

>----- Original Message -----
>From: Valerio Bellizzomi <devbox at selnet.org>
>Date: Sunday, August 12, 2007 5:21 am
>Subject: Re[2]: [cap-talk] Declaring a victory - Delegation Bounds
>To: jed at nersc.gov, cap-talk at mail.eros-os.org
>
>> On 11/08/2007, at 19.03, Jed Donnelley wrote:
>...
>> >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.
>
>From: Valerio Bellizzomi <devbox at selnet.org>
>Date: Sunday, August 12, 2007 5:21 am
>Subject: Re[2]: [cap-talk] Declaring a victory - Delegation Bounds
>
>> 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.
>
>I don't understand how the above "delegate N" mechanism
>can be helpful.  Firstly, how is one to determine "N"?

If 'pass once' makes no sense, and 'unlimited delegation' is undesirable,
'delegate N times' could be a good trade-off.

>While I can understand at least some rationale for the
>case when N = 1 (though as I mentioned above this
>isn't really effective because it blocks object composition
>thereby forcing proxying for this legitimate purpose),
>I don't understand how a case can be made for N > 1.
>Are you suggesting some sort of knowledge of the
>structure of a 'package' of objects where it is known
>that they need to communicate a capability N times
>but not more?   Change the design of the package
>and N changes?  This seems impossibly awkward
>to me, so I guess I'm not understanding.

Yes, this is one of the options: N determined statically by some call
graph.
Another option is N computed at near-call boundary.
Near-call means calls to objects within an application boundary.
Far-call means calls to objects outside an application boundary.

>
>On the other hand a VOC block on delegating
>a capability at the level of higher level identifiers
>(e.g. people) makes better sense to me and
>to the others I spoke to at HotSec.  For this situation
>one is allowing (encouraging) further object
>decomposition in any way it can most effectively
>be done - potentially with additional capability
>communication within the pieces, but (as I noted
>before:):

I don't understand what VOC is, and I don't know the Horton protocol.

>
>> >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.
>...
>This (being able to support access control policies
>at the level of responsible identifiers such as people
>as Horton supports) 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