Re: setuid/setgid binaries contained in the Debian repository.
On Mon, Aug 11, 2003 at 06:13:10PM +0200, Emile van Bergen wrote:
> On Mon, Aug 11, 2003 at 10:33:47AM -0400, Matt Zimmerman wrote:
> > I don't follow. The wrapper is running with uid games, and it exec()s
> > the actual game. So the game is running with uid games, exactly as if
> > the game itself were setuid, and if the game is exploited, uid games is
> > compromised (and so is the wrapper).
>
> If the game is exploited, its uid is exploited, but *only* that uid, not
> the user that has invoked it or any other future user that invokes it.
Right, but its uid owns executable programs, and thus "owns" any user who
runs those executables.
> > The only barrier I see is that it would clean the environment variables.
> > Yes, this is a popular attack vector, but it is by no means the only
> > one.
>
> No, but it helps. Everything that the wrapper can do will help protect the
> game.
>
> The point is that if the game is *still* compromised, nothing is lost but
> the files that can be written by this particular game's uid, which should
> be nothing but its own highscore files. Not a problem. A given game's
> highscore files need to trust that game anyway.
The problem is that the game will often trust the high score files, not the
other way around. If a wrapper solution is to work, it needs to prevent the
need for security within the game itself, entirely, by providing a secure
sandbox. This is by no means trivial, and triviality is the most desirable
feature in a wrapper program (for purposes of auditability and obvious
correctness).
> Good point, but that's easy to fix, and the fix is necessary to get rid of
> the user's supplementary groups as well -- it turns out a normal user
> cannot trim its own group list using setgroups.
>
> To make the wrapper unwritable both by the user and the per-game uid/gid,
> make it setuid root, setgid to the per-game uid/gid, have the wrapper call
> setgroups to get rid of the group list, obtain the desired new uid/gid
> from the effective gid given by the filesystem, call setgid, call setuid
> to set the real, saved and effective uid.
This is now adding quite a bit of complexity, and a setuid root program to
boot (which, it seems, is now also setgid). And what have we gained?
Shared high scores?
I would rather see a tiny setuid program which sanitizes and records high
scores, which is invoked by the game, which runs with the privileges of the
user (or, for extra high-score paranoia, setgid, where only gid games can
invoke the high score manager). I believe joeyh described a system somewhat
like this. This also has complexity to be counted against it (and would be
difficult to integrate into many games), but at least it does not involve
root in the process.
> Example:
> [...]
> /usr/lib/games:
> -rwxr-x--- 1 root quake 1234567 Aug 11 16:30 quake (real binary)
What is the point of restricting execute permission on this unprivileged
program?
> /usr/bin:
> -rwsr-s--- 1 root quake 6231 Aug 11 16:30 quake (from wrapper.c)
I don't see why this should be setgid. It seems the setgid bit is only used
to store configuration information (which uid the wrapper should change to).
This may as well be hard-coded in the wrapper, since a separate copy of the
wrapper will be necessary for every game anyway with this scheme.
> int main(int argc, char **argv)
> {
> static char realgame[PATH_MAX];
> static char *gameenv[] = { 0 };
Having a completely empty environment will surely cause problems; a trusted
PATH at least should be set, and things like TERM are required for proper
operation of many games (though presumably not Quake, which isn't
terminal-based). You also need some way to tell the game who the user is,
for record keeping purposes.
> Any user that's a member of the group 'quake' can run /usr/lib/games/quake
> as user 'quake', group 'quake', nothing else. Neither the user nor 'quake'
> can write to the wrapper.
> Now, if this is insecure for any reason, I'd like to hear why, because then
> it seems unix has a fundamental problem.
Unix has fundamental security problems; this is not news. The security
history of the entire setuid paradigm is awful.
I don't see any obvious security vulnerabilities in the privileged part of
your system, but there are functional problems, which would severely cripple
or break most of the games in Debian, which would need security-conscious
solutions (such as passing environment variables and command-line
arguments).
--
- mdz
Reply to: