Standardizing various games packaging things across distros
Hans de Goede
hdegoede at redhat.com
Thu May 5 01:32:40 PDT 2011
Hi all,
On 05/04/2011 04:48 PM, Bas Wijnen wrote:
> Op 04-05-11 14:53, Jon Dowland schreef:
<snip>
>>> 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.
>
Correct.
> 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.
Agreed, which is still an issue.
> 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.
The separation between users is lost, one user can now get access to another
users files, like say private ssh / gpg keys...
> 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.
An interesting approach, but likely more work then my solution, for both
our solutions the game needs to be reworked to keep the file open
until it exits, rather then open/close it each read/write. Once that
is done, adding one fopen and a dropping of right at the top
of main, is quite easy, and approx. the same amount of code as inheriting
an fd from a parent. This approach is just as safe as yours, once
the rights have been unrevokably dropped, nothing bad can be done any
more other then what can be done through the fd. If there are bugs somewhere
in the kernel / libc which still allow some exploit, there are much bigger
suid / sgid targets then some game.
So I think the safety of the 2 approaches is about equal, where mine
approach does not require an external helper, modified desktop files/
launch scripts, etc. Not to mention Fedora already has patches for
my solution for quite a large number of games.
Regards,
Hans
More information about the Games
mailing list