Hi All,
Recently the thought has popped up in my head more then once, that it would
be good to standardize various game packaging related things between
distros, so that we can send a consistent message to upstreams hiow
we would like to see various game related things handled.
I've made a list of points which I would like us to come to some
start of standard for below:
1) /usr/bin versus /usr/games
Some games get installed into /usr/bin, others into /usr/games,
in Fedora we've standardized on just putting all game executables
into /usr/bin, since /usr/games is not in the default PATH and
thus breaks starting the games from the cmdline
Note that the FHS thus contain /usr/games, but lists it as
optional (together with illustrious things such as /usr/X11R6).
2) /usr/share/<gamename> versus /usr/share/games/<gamename>
FHS: /usr/share/games Static data files for /usr/games (optional)
So it seems that from an FHS pov, this goes hand in hand
with having a separate bin dir for games, in Fedora we've
choosen the same route as with /usr/games and try to
just but data files in a subdir directly under
/usr/share. This seems the most consistent to us, since
this is how most non game packages do things, and we don't
see why games should be different here.
3) /var/games versus /var/lib/games
FHS: /var/games Variable game data (optional)
To me this is the one case where having a separate dir for games
makes sense for global highscore right management, just like we
also have a default gid for games, for sgid games. In Fedora we
we (the Games SIG) have chosen to standardize on /var/games,
which I must admit as I write this is a bit inconsistent,
since we did choose not to use the other 2 optional games
dirs from the FHS.
Some games by default use /var/lib/games instead of /var/games,
all gnome games do this for example. From one pov this is somewhat
consistent with the not using of any optional games subdirs
from the FHS (gnome does not use /usr/games nor /usr/share/games),
from another pov this is just having a special games dir under
/var in a different place then the one advised by the FHS.
4) Handling of sgid rights for shared/global highscore files
Many games support a global highscore table shared between different
users, this usually involves sgid games rights, combined with
a gid games writable score file somewhere under /var.
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.
This leads to the following potential attack scenario:
1) attacker starts a sgid games game, subverts it
2) attacker writes invalid data crafted to subvert
2a) the same game, to the highscore file
2b) another game, to another highscore file
3) intended target starts the game with the malicious
highscore file
4) game does things the attacker wanted with the targets rights
This is in all honesty not a very likely / easy scenario, and likely
the attacker will choose a different attack vector to its intended
target. Still it is something to keep in mind. There is little we
can do to avoid the 2a scenario, other then audit the highscore
table loading code, and hope we catch all bugs.
The 2b scenario however can be fixed. The usual approach with
elevated rights binaries, with a longer then do one thing and exit
lifetime, is to do the things for which the elevated rights are
needed asap after startup and drop all rights. Many games however
don't do this.
The Fedora Games SIG is advocating (and has patches for) handling
global highscore files the following way:
1) open the global highscore file r+ as first thing in main, with a
fully hardcoded path
2) drop all special rights
3) keep the highscore file open until the program exits, and rather
then doing fopen / fclose use rewind and fflush.
Doing things this way limits what an attacker can do when it
subverts a game with global highscore support to corrupting the
one highscore file, instead of being able to do anything made
possible by the gid games rights...
We've been patching games to work this way for a while now, and
this works for 95% of them (the one exception being rogue likes
(*) with their bones files, etc.). Most upstreams have pretty poor
practices here, we've encountered the following variants:
1) no rights handling at all
2) seteuid / setegid tricks, which offer almost no protection,
since the attacker can simply do a seteuid itself to get
the elevated rights again
Regards,
Hans
*) In Fedora we've chosen to create a new gid for each rogue
like, and making its /var dir writeable by that gid, thus limiting
the damage which can be done when it is subverted to only writing
files in that dir.
_______________________________________________
games mailing list
games@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/games
