Op 04-05-11 14:53, Jon Dowland schreef: > On Wed, May 04, 2011 at 10:13:28AM +0200, Hans de Goede wrote: >> 1) /usr/bin versus /usr/games > > (I think) we've taken the opposite route and put them all in /usr/games. > /usr/games is in the default $PATH on Debian. Yes, but not for root. I think the main feature of using /usr/games is that it is possible to make it unaccessible for a group, thereby locking that group out of gaming. I know of people who have an account set up like that exactly because they don't want to play games while studying. (So for study, they log in as the non-game account, but for leisure, they log in as their "normal" account. >> 2) /usr/share/<gamename> versus /usr/share/games/<gamename> >> >> FHS: /usr/share/games Static data files for /usr/games (optional) > > Again we seem to have gone the opposite route and followed the FHS. AIUI both are following the FHS. It seems to make sense to use both /usr/games and /usr/share/games, or none of them. OTOH while I do like /usr/games, I quite dislike /usr/share/games, because I expect package data to be in /usr/(share|lib)/packagename/. I agree with Sylvain that getting rid of special data dirs for games would be a Good Thing. However, I'm not so sure about $(bindir). >> Having sgid binaries brings certain security issues with it, and >> as we all know most games have not been written really robust >> when it comes to dealing with unexpected input / error handling. The attack vector you describe requires two bugs: one which allows you to take over a random game, and one in the highscore parsing code of the target game. But I disagree that this would be a problem. Root doesn't run games (or at least (s)he shouldn't, which is why /usr/games is not in the root $PATH). So the security issue is that one normal user would be able to execute arbitrary code (in the worst case) as another normal user. The fact that this other user also is sgid games is irrelevant. The original bug which allowed the attacker to write the invalid high score data already provided sgid games access, so nothing new is lost. Your solution (opening the high score file early and dropping rights) sounds nice (and solves a real problem), but not optimal. Best would be to let the game run without any special rights from the start. Instead of getting the file handle for the high score file from open(), it should get it from its parent process. The game should be started by a sgid games game starter, like this: game-start /usr/share/games/mygame/highscores /usr/games/mygame This program (game-start) would be sgid games, it opens the first argument, drops sgid rights, and execs into its second arguments (optionally with parameters). That way, we only need to secure start-game; the games binaries are just as safe as other games without special rights. Actually, such an executable would also solve a problem I had with the pioneers meta-server. It runs as a daemon and wants to write into /var/run/. It must be setuid root for that. I don't like that at all. I would be much more comfortable with a separate start-daemon program which gives me a handle to the file in /var/run (start-stop-daemon doesn't seem to do that, unfortunately. Perhaps the best approach is to create a patch for it). Thanks, Bas _______________________________________________ games mailing list games@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/games
