[cap-talk] Declaring a victory - Delegation Bounds

[Valerio Bellizzomi]

On 12/08/2007, at 16.53, Norman Hardy wrote:

>On 2007 Aug 12, at 3:17 PM, Valerio Bellizzomi wrote:
>
>> On 12/08/2007, at 22.34, David Hopwood wrote:
>>
>>> Valerio Bellizzomi wrote:
>>>
>
>
>>>
>>> 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.
>>
>How does he who chooses N learn of the correct value?

A parser explores the call graph, and increments N at each call level.

>Does he ask the agent to whom he will pass the limited capability?

No.

>In that case why not just trust that agent to apply a limit (N-1) to  
>anyone to whom he passes it.

The 'pass N times' is useful to limit delegation within application
boundaries (for some closely held cap). Once the capability must pass the
boundary, it is necessary to increment N. But in this case, the receiving
agent has limited possibility of re-delegating. For example:
N+1: receiving agent cannot re-delegate at all.
N+2: receiving agent can re-delegate up to one sub-level.
etc..

This seems interesting to me.

>Recursively there then seems to be no need of the mechanism.
>What if different parts of the application requires different limits?

Nothing excludes that N can be per-module.

>
>
>
>
>>
>>>
>>> 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
>>
>>
>>
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
>Norm Hardy: <http://cap-lore.com>
>
>What has always made the State a hell on earth has been precisely  
>mankind's attempt to turn it into a paradise.
>Friedrich Hölderlin (1770-1843)
>
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk