[cap-talk] the "flaw" of separating designation from authority

[Karp, Alan H]

Fred Spiessens wrote:
> 
> A deputy D that avoids being confused by requiring his client C to  
> provide a capability Fcap to write to file located at "/deputy/ 
> clientData.txt", could also avoid confusion by:
> - requiring C to provide a certificate to write to a certain file :  
> Fcert  (unforgeable)
> - requiring C to provide a designation of that file: "/deputy/ 
> clientData.txt" (forgeable)
> - requiring C to provide Fcert and " /deputy/clientData.txt" in the  
> same invocation (to be sure its the same client C, invoking D 
> for the  
> same purpose)
> - use Fcert and " /deputy/clientData.txt" together (as if 
> they were a  
> single capability)
> 
I'm not sure I fully understand the example, but it sounds like it is
subject to a mistake we made in Client Utility.

The essence of the problem is that the deputy is issuing a single
command using some of its authorities and some of the user's.  It can be
confused if it can't specify which authorities to apply to which
arguments.

The Client Utility originally associated a specific authority with each
argument.  That later got "optimized" into a set of authorities for all
arguments without anyone identifying the vulnerability.

_________________________
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
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20061025/4fdc07a3/attachment.vcf