[cap-talk] Declaring a victory - Delegation Bounds
David Hopwood
david.hopwood at industrial-designers.co.uk
Sun Aug 12 17:34:37 EDT 2007
Valerio Bellizzomi wrote:
> On 12/08/2007, at 6.23, Jed Donnelley wrote:
>
>> 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.
No, it's the worst of both worlds: you can't reliably delegate, and
you don't know what N should be in order to enforce any useful
security policy.
Remember, the proposal is only to control delegation across principal
boundaries. The primary reason why 'pass once' makes no sense goes
away when you allow arbitrary delegation within a principal boundary.
(I am being deliberately vague about what consitutes a principal --
it does not necessarily have to be a human user's account. Controlling
delegation between applications also makes sense.)
--
David Hopwood <david.hopwood at industrial-designers.co.uk>
More information about the cap-talk
mailing list