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

[Marcus Brinkmann]

At Wed, 24 Sep 2008 16:38:36 +0000,
"Karp, Alan H" <alan.karp at hp.com> wrote:
> 
> Marcus Brinkmann wrote:
> >
> > But frankly, what's the big fuzz then?  Every unix game that keeps a
> > system wide high score faces the same issue, and it's no big deal to
> > setuid the game and open the high-score (or compiler billing file)
> > under a different authority than the user's before dropping to the
> > user's ID and continuing.
> >
> Say that a new version of the game takes input from the user
> specifying the file to hold the saved game.  What happens if the
> user specifies the high-score (or billing file)?  Did the developers
> get the setuid and dropping of rights correct with this
> unanticipated use pattern?  Were the developers of the modification
> even aware of the privilege elevation?

Assuming that such a useless feature is proposed, implemented and
deployed without raising any eyebrowes despite the fact that the
setuid/setgid mechanisms are well understood and a number of
developers and users are involved in the process, what would happen on
a Debian or Ubuntu system is that the user could cause the highscore
file of a different game to be overwritten, because those are the only
files that are writable by group "games".

There are a number of socio-economic factors at work here as well.
Games are low-profile products and thus you will probably find more
security related bugs in them compared to others, but in Debian at
least there was a time where maintainers were very conscious about
this and a lot of security problems related to games were hunted down.
And of course, most systems today are single-user, so the risk
scenarios have changed significantly.

I am not saying that there can't be a qualitative difference per se.
But we should be careful in picking out examples, in order to make the
strongest points possible.  I am not as of yet convinced that a finer
partition than what ACL based systems can conveniently provide would
provide a significant advantage.

> To quote Norm again, "When the code was written to produce the
> output it was correct! What happened to make it wrong? The precise
> answer is that it became wrong when we added home files license to
> (SYSX)FORT. To determine this, however, would have required
> examination of every situation in which the compiler wrote a
> file. Even when we identify those situations it is not clear what to
> do."  That doesn't mean that it's impossible to write a program that
> won't be confused, but it's an easy mistake to make, especially as
> the code evolves.  There are very few capability patterns that lead
> to confused deputy, and the ones I know all involve increasing the
> rights associated with a passed capability.

I take your word for it, but I have doubts that your experience would
be representative across the spectrum of future developers, should
capability systems find broader application.

> > Norm documented a couple of ways how to not do this (matching file
> > names with regular expressions, for example).  But this does not
> > mean that there isn't a better way to do this even in ACL-based
> > systems.
> >
> Polaris solves the problem in an ACL system, but it's a kludge.
> (Actually, it's quite an elegant kludge given the constraints.)  I'm
> not convinced that an ACL-based solution can be better by any metric
> other than legacy compatibility.

That is a strong statement to make, considering that there are many
more metrics than restricting authority in any real world system, and
the most persuasive arguments for capability systems are about
restricting authority and not any of the other many things people are
interested in.  It is not a priori clear to me that the properties of
capability systems you like most can be preserved once the other
demands are brought in.

We may never find out, though: Legacy compatibility is not in the
least a small issue all by itself.  It's of enormous economic
significance, and may all by itself outweigh all security advantages
of a more protective system many times over, at least in the mainstream.

Thanks,
Marcus