Hi, 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 suffice. 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. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpRc8Inq9p0w.pgp
Description: PGP signature