[cap-talk] Confused Deputy, multiple authorities

[Sandro Magi]

Jed at Webstart 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.
>   

I think Charlie is correct. Since passwd runs only with root authority,
the user's authority never enters the picture. As long as the user is
permitted to run the passwd command (dictated by the permissions on the
passwd executable), root authority then takes over. Multiple (disjoint)
authorities are never handled simultaneously and the program cannot
become confused. "root" authority is not even necessary; even if
passwords were managed by some unprivileged user, the confused deputy
cannot occur in this instance.

Perhaps a more appropriate example is cdrecord. It is a setuid
executable that accepts a cd-rw device path as an argument. Using
cdrecord, you could potentially write arbitrary data to the hard drive
containing the root file system.

I think the way to solve the confused deputy in identity-based systems
is to partition the program into separate subprograms each with distinct
identities. Norm's confused compiler (let's say "cc"), would have a
separate setuid program (let's say "bill" ). "bill" is setuid
"billuser", while the "cc" runs with the user's authority.  The billing
file is r/w only for "billuser". When "cc" attempts to open the
malicious user's output path (the billing file), it would fail the
permission check.

This is how secure cd burning can be done in Linux/Unix. cdrecord is
often setuid to some sort of cdrom user (usually a group actually), and
the cd-rw device ownership is also set this way. Thus, cdrecord can only
write to explicit cd-rw devices, but not the hard drive device that
contains the root file system.

The proliferation of new identities and permissions for each explicit
authority seems quite cumbersome to setup and manage though. This
establishes a tension between fine-grained security and aggregated
functionality for usability. You can never handle multiple authorities
in a single program without opening yourself to the confused deputy!

Finally, so far it seems that the confused deputy can only occur when a
program utilizes multiple authorities, AND accepts direction from user
input (such as a path to read/write). Thus, setuid programs which accept
no such direction (such as passwd), are not subject to the confused
deputy. Or am I confused? :-)

Sandro