[cap-talk] Declaring a victory - Delegation Bounds

[Norman Hardy]

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?
Does he ask the agent to whom he will pass the limited capability?
In that case why not just trust that agent to apply a limit (N-1) to  
anyone to whom he passes it.
Recursively there then seems to be no need of the mechanism.
What if different parts of the application requires different limits?




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