[cap-talk] More Heresey: ACLs not inherently bad

[Marcus Brinkmann]

At Tue, 23 Sep 2008 15:22:38 +0000,
"Karp, Alan H" <alan.karp at hp.com> wrote:
> 
> Marcus Brinkmann wrote:
> >
> > I don't think that this is an example of a confused deputy, because
> > there is no deputy.  Instead, the user just manages the authority he
> > has and distributes it among the programs he runs.
> >
> You can still get confused deputies.  Say that Bob has given Alice a capability to a file to compile and a capability to a file to hold the output.  Unbeknownst to Alice, the latter is a read capability to her billing file.  Should the process running the compiler reauthenticate in order to update the billing records, the ACL will increase the authority of the capability for the output file, and Alice will lose the contents of her billing file.  This problem cannot occur if the ACL is used only to restrict the set of permissions represented by the capabilities.

In the scenario you describe, the consequences would be as you say on
the GNU/Hurd.  This is no different from, let's say, a GNU/Linux
server mismanaging saved uids.  You may want to think of the Hurd's
ACL service as a more flexible form of Unix uids and gids (more
flexible because it is possible in the GNU/Hurd to carry an arbitrary
number of IDs with a single capability).  I only claim that there are
real world scenarios where the described feature is safe and useful,
not that there is no way to shoot yourself in your foot.

The interesting question is if useful real world systems can be
constructed that do not have any such operations.  A system in which
principals can only ever diminish their authority and never increase
it does not sound too useful to me.  So, this can not be true in the
strictest sense, and the only questions are about the quality of the
policy and methods used to increase the authority of a principal.

Systems in which the confused deputy problem can not exist seem to
have unworldly properties: For example, any two users of such a system
either have identical authority or can not communicate within the
system at all (proof: if they can communicate, and have different
authority sets, a confused deputy example can be constructed).

The key insight here is that if people can not use capabilities to
name extra authority they desire from the deputy, some other naming
mechanism will be used.  A pure capability system does not guarantee
that confused deputies are not possible, it only means that confusion
occurs over something else but capabilities, for example over file
names.  Specifically, if a real world scenario requires that Bob can
write to files that are only writable by Alice, programmers will come
up with a solution for that.  For example, they will require Bob to
designate a file name in the file name space of Alice.  If everything
else fails, Bob will call Alice on the phone and tell her what program
to execute for him.

Coming up with mechanisms and policies that reduce the risk for
confusion and still allow for a rich collaborative environment is a
challenge in any system, at many layers.

Thanks,
Marcus