[cap-talk] Confused Deputy, multiple authorities

[Charles Landau]

At 6:52 PM -0700 10/19/06, Jed at Webstart wrote:
>At 03:54 PM 10/17/2006, Charles Landau wrote:
>  >And while I'm criticizing Confused Deputy examples, the passwd
>>example in http://en.wikipedia.org/wiki/Confused_Deputy is either
>>poorly explained or not really a Confused Deputy example. Where are
>>the multiple authorities? The passwd command isn't using any
>>authority from the user.
>
>which I didn't write, but I also didn't correct as I believe I understood
>the sense of "confused" deputy.  The authority of the deputy in
>the case of passwd is root - an authority that can change any
>password (and much more) in, for example, the /etc/passwd file.
>The authority of the user making the passwd request is whatever
>their UID is that the passwd command can determine by that
>hack "original UID" mechanism or whatever it is that Unix
>calls it.

The UID is just a number. Passwd isn't using any of the user's 
authority to, say, write the user's files.

Furthermore, the root authority is a superset of the user's 
authority, so passwd doesn't need any authority from the user. It 
just needs to be careful using the authority it has.

In the above, I'm using "authority" to mean authority that is known 
to and enforced by the operating system. Passwd implements a new 
authority; anyone who can cause the "original UID" to be set to X can 
change the password file entry for X. It is straightforward for 
passwd to implement this correctly.

Here is one way to see the difference between passwd and Norm's 
compiler example. The compiler cannot protect its statistics file, 
without resorting to checking that the name of the output file 
provided by the user is different from the name of the statistics 
file. Even that may not work; what if the name is a link or symbolic 
link? (Norm: what was the actual resolution of this problem?) Passwd, 
on the other hand, just needs to take the "original UID" and change 
that entry. How can passwd be "confused"?