[cap-talk] capabilities Q, SetUID and ambient authority problems

[Jed at Webstart]

At 08:31 AM 6/16/2006, Karp, Alan H wrote:
>Jed wrote:
>...
> > Probably they'd also zone out if you mentioned "suid" programs,
> > but to me that seems a key place where confused deputies arise
> > in today's computer systems.
>
>Then I'd have to explain what suid does, why you'd use it, blah blah
>blah.  Remember, few of the people I present to speak Unix.

Right, but remember what the basic point is that we're trying to get
at (if I have this right), namely the added value that comes from
using a POLA (e.g. almost necessarily "capability") approach to
authorization rather than "ambient authority" (users, groups, etc.).

The fact is that something like SetUID is the only means feasible
for any sort of "deputy" to work under an ambient authority model.
That is, as soon as a program running on behalf of one user needs
an authority that the user doesn't have, the only option in an ambient
authority system is to run as some other user with other authorities -
hence SetUID.

I believe by pointing out the need for and limitations of SetUID the
problems with ambient authority (the typical authority as "user")
model becomes clear.  There are many, many seemingly very
simple and useful services that work quite naturally in a
capability world as "deputies" that are so complex and
unnatural that they are never even attempted in an ambient
authority world.

For example, just consider Norm's original confused deputy
example.  I find it quite impressive that the author(s?) would
even attempt to do such a thing (despite how natural and
simple it seems in principle) in an ambient authority
system.  The fact that such an implementation effort
ran into problems isn't at all surprising.  The fact that there
are so many problems with SetUID programs in the Unix
world is also not surprising.  What is surprising is that
there aren't more such problems.  I think this results from
the fact that very few such efforts to mix the authorities
of more than one user are ever attempted in the Unix
world and most such efforts have long histories of
being worked on and eventually pounded into a reasonable
shape - even though if you look at the code its quite
awkward and difficult to understand what's going on.

Just consider the problem of a program running as
some effective UID but with a different "real" UID trying
to determine if the user with the real UID had access
to a file.  What does the program do?  Start examining
ownerships, group, and access bits itself?

>   Besides,
>the example of Bob asking Alice to do something Bob can't do but Alice
>can is exactly the suid example without the technical detail.  I've
>found that precision often interferes with communicating the idea at a
>conceptual level.

That's true, but there are examples of such things in the ambient
authority world - e.g. Unix.  I think it's important to convey
what the basic problem is with such a world view.  To me
one can only really understand what is wrong by looking at
the horrific difficulties one inevitably gets into when trying
to use the only means available, namely SetUID, to mix
authorities from multiple users.

(Well, I guess I should say that the client/server model is
also available.  However, the client/sever mechanism also
has problems mixing authorities between users.  In principle
one can pass open file descriptors from a process running
as one user to a process running as another [e.g. as
Plash does], but then the client and server must run on
the same system - not usually something the client/server
model wants to be restricted to).


I think it's difficult to really understand the value of the
capability/POLA model of computing unless you can
effectively contrast it with the necessary awkwardness
of even very simple mixing of authorities with the
ambient authority model.  That means looking at the
problems with SetUID as that is the dominant means
for dealing with such mixing in the ambient authority
world.

--Jed http://www.webstart.com/jed/