FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Games

 
 
LinkBack Thread Tools
 
Old 05-04-2011, 09:03 AM
Hans de Goede
 
Default Standardizing various games packaging things across distros

Hi,

On 05/04/2011 10:39 AM, Ludwig Nussel wrote:
> Hans de Goede wrote:
>> I've made a list of points which I would like us to come to some
>> start of standard for below:
>> [... ACK]
>> 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
>
> Another attack vector are packages (e.g. %post scripts) that do
> things with group games owned files or directories. There's
> potential to escalate to root by playing symlink tricks leading to
> e.g. a chmod on /etc/shadow or something like that.
>

Well there should simply be no %post scripts messing with these files,
and rpm itself is smart enough to not fall for symlink attacks. Also
notice that my proposed fix, disallows the user to create a symlink in
the first place, all he gets access to if he subverts the game is a
filehandle to the rw opened score file.

> IMO the "global highscore" feature which actually is a "local
> machine highscore" should simply not be enabled by default in distro
> packages.

I disagree, why disable a long standing feature of many of these games,
esp. given that there have been very little security issues with this
even though it has been common practice for ages..

> An ideal solution would be some kind of standardized highscore
> protocol. So games could post their highscore to either a local
> highscore daemon or some service on the internet. I guess that's
> never going to happen though :-)

That would be cool, I agree

Regards,

Hans
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-04-2011, 12:14 PM
Sylvain Beucler
 
Default Standardizing various games packaging things across distros

Hi,

On Wed, May 04, 2011 at 10:13:28AM +0200, Hans de Goede wrote:
> 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.

In Debian, most game packages use /usr/share/games/packagename, but as
far as I'm concerned this brought nothing but troubles (typically
.desktop files ended up installed in /usr/share/games/applications
instead of /usr/share/applications, additional paths to search when
the engine and data are developped independently, etc.).
I didn't see any pro in doing so.

I would gladly switch to /usr/share/packagename for game packages.

--
Sylvain
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-04-2011, 02:48 PM
Bas Wijnen
 
Default Standardizing various games packaging things across distros

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-04-2011, 09:18 PM
Richard Hartmann
 
Default Standardizing various games packaging things across distros

On Wed, May 4, 2011 at 16:48, Bas Wijnen <wijnen@debian.org> wrote:

> 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.

Seriously? I always wondered if there's anybody who is using this distinction.

Personally, I have always thought that separate directories are a bad
idea. There is no /bin/X/ or /bin/networking , either. And for good
reason.

One could argue that data dirs are special. With some games having
huge data dirs and SSDs on the rise, this could make sense for some
scenarios.


Overall, I prefer Fedora's approach. Maybe it's worth bouncing this
off of debian-devel to get more input? _If_ this is changed, it should
be changed globally, preferably at the same time for a lot of packages
at once and become a release goal for next stable.


Richard
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-04-2011, 09:43 PM
Miriam Ruiz
 
Default Standardizing various games packaging things across distros

2011/5/4 Richard Hartmann <richih.mailinglist@gmail.com>:
> On Wed, May 4, 2011 at 16:48, Bas Wijnen <wijnen@debian.org> wrote:
>
>> 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.
>
> Seriously? I always wondered if there's anybody who is using this distinction.
>
> Personally, I have always thought that separate directories are a bad
> idea. There is no /bin/X/ or /bin/networking , either. And for good
> reason.

I agree with you. Even though I can think of some scenarios that might
benefit from the current directory separation, they are too
exceptional to be considered as a serious reason.

> One could argue that data dirs are special. With some games having
> huge data dirs and SSDs on the rise, this could make sense for some
> scenarios.

That might make sense if the distinction was between big data and
small data. There are a lot of games with very small data dirs, and
there are other packages -not games- with big data chunks. If that is
the reason, it seems pretty arbitrary. I guess the reason might be
more along the lines of thinking that games are second class citizens
that are not as important as other packages, and thu the separation in
directories makes it easier to handle their storage differently. As I
say, I can only think of exceptional situations in which that could be
useful, and I know of no one -I knew of no one until now- using that
used that separation for anything.

> Overall, I prefer Fedora's approach. Maybe it's worth bouncing this
> off of debian-devel to get more input? _If_ this is changed, it should
> be changed globally, preferably at the same time for a lot of packages
> at once and become a release goal for next stable.

If there are no serious reasons against it, I'd go for that too.

Greetings,
Miry
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-04-2011, 10:31 PM
Richard Hartmann
 
Default Standardizing various games packaging things across distros

On Wed, May 4, 2011 at 23:43, Miriam Ruiz <miriam@debian.org> wrote:

> That might make sense if the distinction was between big data and
> small data.

Good point. I seem to remember Ganneff talking about creating special
repositories for large data sets (mainly games and scientific data) a
few years ago, but this went nowhere.

Unless Debian as a whole decides to act on this, it's prolly not worth
pursuing a split.


Richard
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-05-2011, 08:32 AM
Hans de Goede
 
Default Standardizing various games packaging things across distros

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
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-05-2011, 08:46 AM
Richard Hartmann
 
Default Standardizing various games packaging things across distros

On Thu, May 5, 2011 at 10:32, Hans de Goede <hdegoede@redhat.com> wrote:

> 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.

Not quite true as with Bas' approach there is exactly one binary that
needs to be secured whereas with your approach every single game
binary needs to be patched and audited. While I am not agreeing with
the people who created a setuid-free Linux distro, it's still good
practice to limit the number of binaries that are setuid.


Richard
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-05-2011, 08:50 AM
Hans de Goede
 
Default Standardizing various games packaging things across distros

Hi,

On 05/04/2011 11:49 PM, Jon Dowland wrote:
> On Wed, May 04, 2011 at 11:43:26PM +0200, Miriam Ruiz wrote:
>>> Overall, I prefer Fedora's approach. Maybe it's worth bouncing this
>>> off of debian-devel to get more input? _If_ this is changed, it should
>>> be changed globally, preferably at the same time for a lot of packages
>>> at once and become a release goal for next stable.
>>
>> If there are no serious reasons against it, I'd go for that too.
>
> What are the serious reasons for it? What advantages are there in aligning
> with Fedora (and going against the FHS)? The cost is -- at least -- changing
> all our packages (DDPO puts that at 265).
>

I'm not advocating anyone changes existing packages, esp. not all at once.
I see no reason why packages could not be moved over one at a time. Likely
both schemes are already in use at the same time already, even in Debian.
For example the gnome-games games use /usr/bin and /usr/share not
/usr/games and /usr/share/games, and I doubt that is different in Debian
(I have not checked), likewise for kde games.

My main reason for starting this discussion is to come to some sort
of agreement which form is the preferred form, so that we can have
some "how to be a good games upstream" webpage which addresses some
game specific things. I would like such a webpage to contain advice
for upstream what to use for the various ambiguities I've pointed
out in my first mail.

Currently various upstreams handle these things in different ways and
we all end up patching some of them to handle things in the way
preferred by our distro.

> I'd like to hear from some other distros to see who else does what before
> considering such a move.
>

Agreed, I would love to get some input on this from other distros too.
I propose that if we can get some sort of agreement between the people
now actively involved we create a "how to be a good games upstream"
wiki page on freedesktop.org, with a list at the bottoms which distro's
have made / agree with the rules listed. Then we can send an announcement
to lwn.net and a few others, and hopefully get more distro's to sign,
or restart the discussion.

Regards,

Hans
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-05-2011, 08:51 AM
Richard Hartmann
 
Default Standardizing various games packaging things across distros

On Thu, May 5, 2011 at 10:50, Hans de Goede <hdegoede@redhat.com> wrote:

> Agreed, I would love to get some input on this from other distros too.
> I propose that if we can get some sort of agreement between the people
> now actively involved we create a "how to be a good games upstream"
> wiki page on freedesktop.org, with a list at the bottoms which distro's
> have made / agree with the rules listed. Then we can send an announcement
> to lwn.net and a few others, and hopefully get more distro's to sign,
> or restart the discussion.

Aye. Labelling it as 0.1 (or 1.0 to get some buzz going) and stating
explicitly that feedback is welcome would help to get in new people
while already providing something to work with.


Richard
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 

Thread Tools




All times are GMT. The time now is 04:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org