[cap-talk] Delegation/Proxy equivalence and limited lifespanobjects?

Jed Donnelley jed at nersc.gov
Mon Nov 12 17:21:29 EST 2007


On 11/12/2007 11:09 AM, Rob Meijer wrote:
> On Mon, November 12, 2007 18:16, Karp, Alan H wrote:
...
>> The result of blocking delegation is to make it harder to get
>> work done without adding security.  That's not the same as claiming that
>> delegation and proxying are equivalent.
> 
> Do you feel the above shows there is 'some' added security to proxying
> over delegation here (even with attenuation patterns in place), that would
> be a valid reason to implement a no-re-delegate bit ?

No.  As was pointed out by others, the destruction of the proxy
object is independent of any relevant security considerations and
can't be depended on for secure functioning.

> I seem to be unable to refute the above, although I have a strong feeling
> that something is wrong in the above observation, I can however not give
> any proven example of any attenuation pattern that would result in the
> same (or better) security properties as the proxying example where some
> objects have a limited lifetime.

You don't have to give up proxying with limited lifetime.  You
just have to tie the termination of the proxy (revocation) to
something not as disassociated as the lifetime of some
arbitrary object that happens to be part of a delegation
chain.  You also have to recognize that delegation is a
good thing that may be needed for functionality and/or
for security (separation of domains for POLA).

For example, I start an application program running.  I
decide that I don't want that program to be able to make
any permanent changes to my access control environment.
I give it access only to revocable capabilities.
At some time in the future I decide that it has done
my bidding and I will now revoke all it's capabilities.
It or other objects that it has communicated to may
or may not still be running.  Regardless I have positive
control and I allowed any needed delegation to happen.

This to me is a demonstration of a more effective
approach than using a "no-re-delegate" mechanism
with the same "security" values but that also allows
necessary re-delegation for functionality with
effective domain separation.

Just say no to no-re-delegate.

I believe those who argue for "no-re-delegate"
really feel that they want to stop effective
delegation even by proxying, but they don't understand
the nature of the Communicating Conspirators problem:

http://www.erights.org/elib/capability/conspire.html

(I won't address the amplification example since
for me it gets into topics that are implementation
dependent and a bit too obscure, EQ, etc.  However,
if others want to spend more time hashing that topic
I'll participate as I am able).

--Jed


More information about the cap-talk mailing list