Standardizing various games packaging things across distros

[Bas Wijnen]

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