[cap-talk] the value of non-delegatable authority?

[John McCabe-Dansted]

On Jan 14, 2008 11:42 AM, Jed Donnelley <capability at webstart.com> wrote:

> If you are to argue for the value of delegating
> with a non-delegatable authority from Aaron to
> Alice then it seems to me you need to consider
> the options available to Aaron.  Aaron has at
> least these three options that seem relevant
> to me:
>
> a.  Communicate the authority directly as a
> capability (reference),
>
> b.  Communicate the authority in the non-delegatable
> manner that you describe, but also
>
> c.  Communicate the authority through any sort
> of a policy engine such as a simple revokable
> capability, a more thorough membrane, an
> identity based delegation tracking mechanism
> like Horton, or any other possible policy engine
> (e.g. indirect through a service that can
> accept any sort of a policy module upload).


One case is where Alice is a legacy module accessed by Aaron. The source
code to Alice may be missing or unmaintainable. A bug in Alice causes it to
leak capabilities, but Alice contains no proxying code. It is discovered
that Alice still functions when passed NDAs. (b) works around this security
hole until a better fix can be found. (c) doesn't help here, even if you
could revoke the capability the instant it was leaked you'd break other
stuff.

I doubt this is very common, but it was mentioned on the AppArmor mailing
list.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080115/a4df58ad/attachment-0001.html