[cap-talk] confused deputy problem

[Toby Murray]

On Thu, 2008-05-29 at 11:05 +1000, James A. Donald wrote:
> Charles Landau wrote:
>  > In that case, this problem could have been solved by
>  > using the Principle of Least Authority, which does not
>  > require capabilities. It seems to me that to justify
>  > the subtitle "or why capabilities might have been
>  > invented", the compiler would have to need write
>  > access to the billing file.
> 
> The problem described, occurs in world that is quite
> unlike our present world.  The problem occurs in a world
> where a single CPU has many users, who do not trust each
> other.
> 

Not at all. The problem described is faced every day in our current
world. Consider websites that have many users who do not trust each
other, and various cross-site vulnerabilities that allow one user to
maliciously wield the authority of another.

The Confused Deputy problem is, I would argue, much more relevant today
than it ever has been before. To be fair, it is of course not the only,
or even the most pernicious, problem out there. But to imply that it has
little relevance today and that, hence, the technologies that can easily
solve it also have little relevance is simply incorrect.

> In the present world, a single user has many CPUs, and
> does not trust much of the software that they are
> executing.  This is a different problem which calls for
> different solutions
> 
> The standard unix way of solving the problem described
> is that each program runs under a user's authority, with
> the full authority of that user, able to do anything
> that user could do.  So if the user could not write to
> the billing file, he could not command the compiler to
> write to the billing file.

You're forgetting setuid. The compiler could get setuid "gcc", where
"gcc" is a user that has write access to a special
file, /var/log/gcc-billing, that ordinary users cannot write to. Surely
web servers like apache are set up in exactly this way?

> 
> This seems a fine way of solving the problem that
> occurred back then, a fine way of solving the problems
> we used to have.

If this is truly the case, you can prove it by solving the cross-site
request forgery and cross-site scripting problems in a similar manner.
The only solutions that I'm aware of fall into two categories, neither
of which can be said to align with the UNIX solution alluded to above
(i.e. UNIX user/group access controls sans setuid):


 - Those that embody the ideas of combining designation with authority,
including making URLs unguessable
 - Those that prevent designations from one domain being used in
another, which is certainly outside the scope of the standard UNIX
access cotnrols and is at best a short term solution that hobbles many
other useful technologies, most notably mashups.