[cap-talk] Declaring a victory - Delegation Bounds
Jed Donnelley
JEDonnelley at lbl.gov
Sun Aug 12 21:22:43 EDT 2007
----- 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/
More information about the cap-talk
mailing list