[cap-talk] Confused Deputy (definitions), capabilities and Unix

Thu Oct 26 16:51:08 CDT 2006

At 06:56 PM 10/25/2006, Ka-Ping Yee wrote:
>On Wed, 25 Oct 2006, Jed at Webstart wrote:
> > > > If D can access "A" with U's authority
> > > > for the purposes of the request by U (as many have discussed in the
> > > > case of Unix), then isn't this limited "Confused Deputy" 
> problem solved?
> > >
> > >That's what 2a is about.
> >
> > I understand.  However, in the case of Unix it seems that there is such
> > a means (though awkward as some say).  From the viewpoint of a Unix
> > programmer/user this problem has been known about and dealt with
> > adequately for years.  Why do we need capabilities?
>
>Norm talks about this a bit in his article:
>
>     http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html
>
>|   The system was modified by providing a new system call to *switch
>|   hats* which could be used to select one of its two authorities. Note
>|   the increase in complexity! The compiler would then be able to use
>|   its home files license or the invoker's license explicitly--in the
>|   later case, for example, saying "by the authority vested in me by my
>|   invoker I hereby request the opening of (SYSX)BILL" which would then
>|   properly fail.

Which if I understand correctly is the recommended and used solution
for Unix.

>It soon became clear, however, that more than two
>|   "authorities" were necessary for some of our applications.

However, seemingly NOT for any applications in Unix - my point.
As I say, Unix has been this way for years and years and has
managed to get by.  Why does Unix "need" capabilities again?

>|   A further
>|   problem was that there were other authority mechanisms besides
>|   access to files. Generalizations were not obvious and the
>|   modifications to the system were not localized.

Again in the case of Unix any needs for authority mechanisms
besides those of access to files (which just about everything in Unix is)
have been found to be unneeded from a pragmatic viewpoint.  So I ask
again, why do we need capabilities rather than just continuing to
use a UID "solution" as Unix does?

>|   (Exercise for the
>|   reader: Show that access lists do not solve this problem.)

With access lists you have the choice of either:

1.  Sticking with ambient authority (changing hats as above) or

2.  Doing zero based access control with every process running
with it's own identity.  This approach is not generally used for
access lists and would be very awkward (all permissions would
have to be "communicated" by updating access lists), but I believe
in principle it could work.

>|   Another indication of poor design is that disparate mechanisms were
>|   necessary to arrange separately that the compiler (1) know what file
>|   to write on and (2) be authorized to write on that file. The crime
>|   was perpetrated through unintended application of the compiler's
>|   authority over SYSX when writing the user's data. (If you try to
>|   solve this problem without capabilities, remember that the file
>|   (SYSX)STAT must also be protected.)

I believe one can argue that this aspect of "the problem" is at least as
easy to manage under an ambient authority system.  In that case I
only have to remember which "hat" to wear whenever I'm performing
an operation.  With a capability system one must remember which
capabilities came from a client and be sure to use only those in
the appropriate contexts.  I don't see much difference there.

Now transiting back to my usual role as a defender of capabilities:

Capabilities get you POLA.  Exactly the needed permissions
can be communicated.  With capabilities the deputy needn't be
allowed to run with all the authority of the client, so you get
the ability to run with mutual suspicion.  I argue that this is
particularly important over a network (where of course the notion
of a UID typically doesn't transit) but then of course you need
a network standard for capabilities - which I haven't found much
traction getting attention for on this list (e.g. my multiple references
to: https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D
which, for all it's flaws, at least is a network capability and something
along those lines [e.g. YURLs] could be promulgated as a standard).

I don't think that we as capability advocates should hang our hats
on the Confused Deputy problem (at least in the limited sense
defined by Norm).  It simply isn't considered a "problem" on Unix.
Perhaps there is some awkwardness (e.g. with SUID programs
that are not SUID root where in general the program can't run with
the client's UID - i.e. no mutual suspicion), but Unix is and has
been a working system for many, many years and people who think
along Unix lines simply don't feel the need (really need) for
POLA/capabilities.  Generally they feel that capabilities would make
Unix horrifically complex and unusable and would result in a
worse system.

I'm currently reviewing a critique of the Hurd with Marcus Brinkmann
and Neal Walfield.  I believe one could argue that the Hurd is the
best and greatest effort so far to add capabilities to Unix.  In my
opinion it's a mess.  Firstly the capabilities are not "persistent".
That is, they disappear/become invalid when the system reboots
(like processes).  Try to imagine such permission tokens used
in a network (even with something like the DCCS to translate
them from system to system).  I receive a capability.  I do some
work and then try to use it.  It doesn't work.  What happened?  Oh,
I beg your pardon.  You say your system rebooted??  Mine
didn't.  Grumble.

This non persistence of capabilities may well be inherited from
Mach.  In my opinion it simply needs to be fixed before the
Hurd (or any other effort to "add" capabilities to Unix) could be
taken seriously.

I believe very strongly that the only way to make capabilities work
effectively is to implement them as a persistent network standard.
We can use caching techniques for local performance optimization
if desired, but people (in addition to processes/active objects) need
to be able to use capabilities, and people don't "reboot".

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