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

[Fred Spiessens]

On 25 Oct 2006, at 18:10, Karp, Alan H wrote:

> 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.

It's hard to explain, and I should not have used file location but  
some permanent file identity (unique, permanent, but forgeable).
Let my try to clarify.
Fcert has all the authority and is unforgeable, but cannot be used  
like a capability, because, even if it contains a file designation  
hidden in its internals, it is not a file reference. It could be a  
statement, signed by the security kernel, that states : "The holder  
of this certificate is allowed to write to the file with permanent ID  
12345."
The protection system will have to check if the (forgeable) file ID  
provided as the designation, matches the certificate.

> 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.

In the example, the deputy can specify that the authority  provided  
by its client should be applied to the  designation provided by its  
client.  For instance the deputy calls:
MyFileSystem.writeFile(fileID: 12345  certificate: Fcert  data: "XYZ").

>
> 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.

  Interesting, Client Utility may have discovered another kind of  
flaw, or maybe a variant of the confused deputy problem (as I  
understand it), that shows designation and authority really have to  
be combined. I would like to understand that flaw then.
Let me repeat, just to be clear, that I did not propose an  
alternative for capabilities. I only want to question the reason why  
capabilities can avoid confused deputies: I think it is not the  
combination of authority with designation, but the fact that (all)  
permissions are "portable".

Fred.