On Jan 14, 2008 11:42 AM, Jed Donnelley <<a href="mailto:capability@webstart.com">capability@webstart.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you are to argue for the value of delegating<br>with a non-delegatable authority from Aaron to<br>Alice then it seems to me you need to consider<br>the options available to Aaron. Aaron has at<br>least these three options that seem relevant
<br>to me:<br><br>a. Communicate the authority directly as a<br>capability (reference),<br><br>b. Communicate the authority in the non-delegatable<br>manner that you describe, but also<br><br>c. Communicate the authority through any sort
<br>of a policy engine such as a simple revokable<br>capability, a more thorough membrane, an<br>identity based delegation tracking mechanism<br>like Horton, or any other possible policy engine<br>(e.g. indirect through a service that can
<br>accept any sort of a policy module upload).</blockquote><div><br>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.
<br><br>I doubt this is very common, but it was mentioned on the AppArmor mailing list.<br></div></div><br>-- <br>John C. McCabe-Dansted<br>PhD Student<br>University of Western Australia