[cap-talk] Declaring a victory - Delegation Bounds

[Valerio Bellizzomi]

On 12/08/2007, at 22.34, David Hopwood wrote:

>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.

Yes I know, N should be exactly as large to reach the application
boundary.
I don't talk about enforcing policies, I talk about mechanisms.
If an application is known to have a static set of objects, then N can be
determined at compile time by the application call graph.
If an application is known to create new objects at run-time, N could be
incremented at run-time, computed to be within the application boundary.
The application boundary could be a membrane.
Ok, so inter-membrane delegation can be achieved too, with some provision
for limited re-delegation from the receiving application. But, of course
all of this requires tracking the delegation chain, that is it involves
some mechanism that tracks delegation and controls the counter.


>
>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.

Delegation would not be arbitrary, it would happen exactly no more than N
times.

>
>(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.)

Here is the problem. In most discussions there is a trend to switch
between principals and subjects. I talk about subjects, that is:
1. principal = user. In this case we don't see why 'delegate N times' is
useful.
2. subject = process. In this case a process can delegate to
sub-processes, how many times?  N times.

Well. It could be principal = process, this doesn't change the fact that
delegating N times is useful.

'Pass once' sounds a lot like 'one time tickets' or 'use and throw
capabilities', which doesn't seems to be the goal.


>
>-- 
>David Hopwood <david.hopwood at industrial-designers.co.uk>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk