[cap-talk] Declaring a victory - Delegation Bounds

[Valerio Bellizzomi]

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

>----- Original Message -----
>From: Norman Hardy <norm at cap-lore.com>
>Date: Sunday, August 12, 2007 4:59 pm
>Subject: Re: [cap-talk] Declaring a victory - Delegation Bounds
>To: "General discussions concerning capability systems."
><cap-talk at mail.eros-os.org>
>
>> 
>> 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.
>
>I agree.  I also don't understand what the expected value is.  Perhaps
>if you can provide an example it would help Valerio.
>
>I don't understand what is intended.  If this is really just a way to
>block capability communication outside some sort of application
>system, why not just do that with confinement?  Don't give the
>application a capability that allows it to communicate capabilities.
>
>You must have an application in mind that does need the
>ability to communicate capabilities (permanent capabilities?)
>outside itself.  I think an example would be helpful.
>
>> > Yes I know, N should be exactly as large to reach the application
>> > boundary.
>
>Then put the block at the application boundary.  Do you feel that
>you don't have a mechanism to do that?
>
>> 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?
>
>I agree.  For me "delegate N" seems to be nearly impossibly
>awkward in terms of it's implementation (e.g. what about
>internal recursion?) AND doesn't do anything that can't be
>more effectively accomplished otherwise.  Perhaps an
>example will clarify the issue.
>
>--JED  http://www.nersc.gov/~jed/

Ok, ok, 'delegate N times' is only an idea, and probably a bad one !
Let's move on.

Val

>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk