Hi, On Mon, Aug 11, 2003 at 09:28:42AM -0400, Matt Zimmerman wrote: > On Mon, Aug 11, 2003 at 10:56:50AM +0200, Emile van Bergen wrote: > > > A more unix-like approach would therefore be to create a separate uid > > for each game, and use a wrapper for each game that's suid to the game's > > uid and executable only by gid games. This wrapper would, clean the > > environment and run the game, passing the uid of the invoking user as > > simple command line or environment information to the game. A "call > > gate" for games, so to speak. > > > > This way, users have no control over the process that runs the game; > > each game runs under a different uid and can have its own highscore > > file, which is guaranteed secure from other games. > > > > In other words, the game doesn't have to trust the user nor does it need > > to trust all other games anymore. Looks like it solves the problem. > > setuid results in even more problems than setgid. Given access to the game > uid, the user can modify the wrapper program (because they own it) and from > that point forward, any user who runs the game is compromised. The point is that the user doesn't get control over the game uid, because the setuid + wrapper that sets the real uid, etc. provides a barrier to the invoking user. We have to trust such barriers; they are required in the unix design. If a user could make any setuid binary do arbitrary things, no matter whether it's correctly written, then it's a kernel bug and we are in much, much bigger trouble. The idea is that the wrapper must be trusted to be able to guarantee dropping all permissions inherited from the invoking user and setting all uids (saved, effective, real) to the per-game uid. After this, the game cannot do anything as the invoking user or to his files. That's the whole point. In short, the setuid wrapper doesn't add any permissions, it effectively drops the invoking user's permissions. Most people don't consider this possibility of setuid. Setgid is a bigger problem because the process retains the permissions over the invoking users files and gains additional permissions. Not so with this scenario. After completely switching to the game uid, if mere user input is enough to have the game run arbitrary code under its per-game uid and do the same when the next user runs it, it won't be able to harm that user in any way, simply because that game uid can't do anything to any user at all. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgplF0JkMYDQS.pgp
Description: PGP signature