[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: setuid/setgid binaries contained in the Debian repository.


On Mon, Aug 11, 2003 at 09:45:50AM +0200, Josef Spillner wrote:

> On Monday 11 August 2003 01:23, Matt Zimmerman wrote:
> > The most appropriate solution, to me, is to use centralized network servers
> > to store and compare this data, rather than local files anyway.
> Some kind of centralized instance has to be used, and sgid is the poor man's 
> approach of doing this.
> It doesn't have to deal with the data in every case though, as the concept of 
> authentication servers does exist.
> Out of all multiplayer games, most simply require a game server "somewhere on 
> the net" these days (peer-to-peer gaming implied), and those that don't can 
> again be divided into split-screen play and the classic way of sharing just 
> the highscore file.
> The latter group could be satisfied with one of the more advanced access 
> control mechanisms, of whose none is enabled by default on any Linux or BSD 
> system, unfortunately. We have ACLs, role models, privacy models, 
> personalities, trustees, capabilities, jails and whatnot, but we don't use 
> them, so the problem is not going away anytime soon.

For the last category, problem of games being persuaded to play tricks
with another game's high score files won't go away unless you can
authenticate the game instead of the user running it. Whether you simply
use sgid or a network server that allows the game to specify its own
name, you need to trust the game code that it doesn't specify another
game's name.

Having the score server look at a name in the process table doesn't do
any good as it can be arbitrarily manipulated by the user (the game runs
under his own uid, so he has full control over whatever the process
does, by hacking it or simply using ptrace). The same goes for
proc/<pid>/exe, for which a simple ln or cp before running the game will

This is a palladium type of problem. You want a binary to run under a
certain user's permissions, but you don't want the binary to trust the
user, and you want a server to be able to authenticate the binary.
That's hard on any unix system, it just doesn't partition that way. The
privilege system only separates uids.

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.



E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

Attachment: pgpLcuSNPwZWD.pgp
Description: PGP signature

Reply to: