[cap-talk] Derivative rights

Karp, Alan H alan.karp at hp.com
Mon Feb 4 19:46:37 EST 2008


ross mcginnis wrote:
>
> This is the crux of the matter.  To me it appears that *any*
> reference is a cap.

In order to provide security value, a capability must be unforgeable.  Where that is not possible, we substitute unguessability.  A guessable filename cannot be considered to be unforgeable, making it useless as a capability that is meant to control even the ability to name the file.

It is quite likely that I could guess you have a file on your machine named "/home/ross/Documents/taxnotes.txt".  By constructing the name out of whole cloth, I have obtained the right to name the file without anyone giving it to me, a violation of capability rules.  Hence, a guessable name cannot serve as a capability, even though knowing the name does give a starting point to mount an attack.

This discussion is not relevant to your example, where Mallory has the right to read the letter but not write it.  The name of the letter could be unguessable, but Mallory needs the right to know the name so she can read it.  In an ocap system, a reference to an object conveys the right to use all the methods of the object.  In order to restrict those rights, we set up a proxy object, a facet, that only forwards a subset of the requests.  In your example, Mallory would only be given the right to name a copy of the letter that nobody has has permission to write, which corresponds to a read-only facet of a file.

> The difference between the cases is that the failing system
> used a reference (a document name) instead of the actual
> document, ie: references are the cause of confusion.

No, the failure is due to the fact that Mallory designated the letter in a manner that did not convey her authority to it.  It is the separation of designation from authorization that is the root case of the confused deputy.  The first case that used the actual letter wasn't subject to this failure because it kept the designation and authorization together.

> References are caps by the general definition of caps.
> (In this specific case the reference is a document name: it
> is cap because- 1) it designates an object -ie: the document
> named, 2) it carries an authorisation due to the fact that
> mere possession of the document-name allows you to test the
> document in the verifier- this is a definite and distinct
> derived right! )
>
A name plus an intended operation allows you to test the document in the verifier.  The name alone does not.  If an ACL system tells you that the requested operation is denied, you don't know if it's because you don't have permission or because there is no file by that name.  In this case, the name alone carries no authority.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080205/4f509c33/attachment-0001.html 


More information about the cap-talk mailing list