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-06-2011, 08:59 AM
Richard Hartmann
 
Default Standardizing various games packaging things across distros

On Fri, May 6, 2011 at 09:02, Hans de Goede <hdegoede@redhat.com> wrote:

> So on one hand we have this approach which looks good on paper, and
> on the other hand we've this approach which looks equally good on
> paper, and which is actually implemented already for a lot of
> games. Which to me makes it really easy to decided which approach
> to choose.

I still disagree about the relative security, but code wins, we agree on that


Richard
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-06-2011, 09:21 AM
Bas Wijnen
 
Default Standardizing various games packaging things across distros

Hi,

Op 06-05-11 09:02, Hans de Goede schreef:
> On 05/05/2011 11:04 AM, Richard Hartmann wrote:
>> On Thu, May 5, 2011 at 10:58, Hans de Goede<hdegoede@redhat.com> wrote:
>>
>>> With Bas' approach every game binary (or rather the sources it is build
>>> from) still needs to be patches to use the passed in fd, rather then
>>> trying
>>> to open the highscore file itself.
>>
>> Correct. This is inevitable unless upstreams adopt either patch.

Plus, both approaches are almost identical when it comes to this patch.
The only difference for the upstream code is what happens at the start.
However, that is a significant difference IMO:

- Your code is 14 lines (excluding comments) of non-trivial (IMO) code.
What you would need for my solution is 2 lines, and it is trivial:

/* At global level. */
FILE *scoreboard_filehandle;

/* In main. */
/* The scoreboard file is opened by game-helper as fd #3. */
scoreboard_filehandle = fdopen (3, "r+");

This means that the executable must be started from the helper, unless
it allows an invalid file handle. For this, the helper package could
provide a script to which the games packages can put a link in /usr/bin:

#!/bin/sh
game="`basename "$0"`"
game-helper /usr/share/$game/highscores /usr/share/$game/$game

game-helper must then of course check that everything is right (the
highscore file exists and is group-writable and the executable exists.

>>> 2) The rest of the code will be a simple standardizes snippet
>>> directly at
>>> the start of main, and once control is passed this snippet all
>>> elevated
>>> rights are permanently gone, see here for the snippet Fedora is
>>> using:
>>> http://fedoraproject.org/wiki/SIGs/Games/Packaging
>>
>> The other approach would also result in one single snippet (unless I
>> am forgetting something)?
>
> Right, so from a security pov and needed patching pov both approaches
> are equal, except that having a special right helper also requires:
> -adding launcher scripts / modifying .desktop files
> -writing such a helper

Actually, with the launcher script above included in game-helper,
.desktop files don't need to be modified, and adding the script comes
down to adding a symlink.

Your approach requires:
- sgid rights on every game with highscores, making it harder to see
which executables require extra auditing attention.
- a significant amount of identical code at the start of each game,
which must all be changed if something is wrong, or something extra is
desired. It really comes down to including a tiny static library in the
source, and has all the problems that come with it.

One such extra feature I'm thinking of right now, is to implement a
standard highscore file format which games can use. Then game-helper can
check if the file is in that format (by reading the header), and if so,
it can check that there is no nonsense in it. That way, it will become
harder to attack a game by writing malicious code into the highscore file.

This just illustrates that my approach is similar to using an external
shared library, with all the benefits that come with it. Of course, when
adding such extra features to game-helper, it should do:
- Open highscore file
- Drop priviledges
- Do extra stuff
- Start game

> More importantly, Fedora has already been using the approach I advocate
> for a few years, and has patches for many games for this already and
> has been feeding these upstream where possible.

That's really good!

> So on one hand we have this approach which looks good on paper, and
> on the other hand we've this approach which looks equally good on
> paper,

Not equally good, IMO.

> and which is actually implemented already for a lot of
> games.

Which means that the bulk of the work for the other approach is already
done as well.

I'm happy to write the game-helper. The rest that would be required is:
- Replace your code snippet with my single line.
- Change the packaging to put the executable in
/usr/lib(/games)?/foo/foo and highscores in
/usr/share(/games)?/foo/highscores
- Let the package make a link to /usr/(bin|games)/game-helper from
/usr/(bin|games)/foo and depend on game-helper.

I agree that this is some work, especially with the packaging. Per game
it's not much, though, and I do think it's worth it.

> Which to me makes it really easy to decided which approach
> to choose.

To me, the downsides of your approach are significant. Of course, they
are even more present in the game without any of these patches. So for
two reasons I'm very happy with the work you've done on this so far:
- It makes things better
- Most of the work you did is usable for what is IMO the best approach,
so your work is not lost if we go there.

Thanks,
Bas
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-06-2011, 09:56 AM
Vitaly Magerya
 
Default Standardizing various games packaging things across distros

> Yes, in practice the discussed attack vector does not seem something
> which often gets used / security bugs get filed for (*). Still I think
> it would be good to agree on a way to best harden setgid games games,
> esp. for the mentioned wiki page with advises for upstreams for games.

If you'd ask me, "open file, drop privileges" is a sensible thing to do,
and pushing such patches upstream is even better, because it will
instantly offer increase in security for all the downstream users
without any work on their part (even those who install programs manually
will benefit).

(Other security concerns, like an exploitable game being able to read
and write all your home directory is more of a pressing matter though).
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-06-2011, 12:03 PM
Bruno Wolff III
 
Default Standardizing various games packaging things across distros

On Fri, May 06, 2011 at 09:09:07 +0200,
Hans de Goede <hdegoede@redhat.com> wrote:
>
> *) Likely because there is lower hanging fruit for blackhats to abuse.

Another issue is multiplayer games. Some games trust servers and clients
that they really shouldn't. They really need to treat them as potentially
adversary's. I know for Wesnoth (when I was spending more time on it), there
were a few of us worried about that kind of thing, but some other games
seem to be very trusting of remotely supplied data. (You more or less have
to trust it for playing the game, but you need to be sure you don't trust
the data when it comes to system integrity.)
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-06-2011, 12:03 PM
Bas Wijnen
 
Default Standardizing various games packaging things across distros

Just replying to my own post with a new idea I got from myself. :-)

> Your approach ... really comes down to including a tiny static library in the
> source, and has all the problems that come with it.
...
> [M]y approach is similar to using an external shared library, with all the
> benefits that come with it.

We can also use a real shared library[1]. This has several benefits and
one major drawback:

Benefits:
- No special code is required at the start of the game.
- Other functionality is easier to add, such as using a highscore server
(locally or on the net).
- Highscore parsing code is taken out of the game to a central place,
which allows us to really close the security hole of badly written games
(as far as high score files are concerned).

Drawback:
- The current code that has already been written by the Fedora people is
not usable, and must be replaced by calls into the library. In fact,
this may mean significant rewriting work for each game.

The benefits are nice, but the drawback is huge. I would like to agree
the following about games with a central highscore file:
- New games and games for which this is initially implemented should be
written to use the shared library.
- Games which already use their own system should be patched using the
method Fedory uses.
- It is considered an improvement, but not a priority, to patch games to
use the shared library instead of their own handling, and thus to move
from the sgid-safe patch to the shared library patch.

I've updated the wiki page on freedesktop.org about upstream to talk
about this: http://www.freedesktop.org/wiki/Games/Upstream
Please feel free to change it.

The library interface I am proposing there is:
* Get the current list of highscores.
* Register a callback to be notified of changes to a list of highscores.
* Unregister the callback.
* Free the list.
* Send a new score, which is potentially a highscore. Returns: position
in the high score list.

Thanks,
Bas

[1] This shared library will need to talk to a setgid games program to
open the actual highscore file. This is an implementation detail.
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-06-2011, 01:42 PM
Hans de Goede
 
Default Standardizing various games packaging things across distros

Hi,

On 05/06/2011 02:03 PM, Bas Wijnen wrote:
> Just replying to my own post with a new idea I got from myself. :-)
>
>> Your approach ... really comes down to including a tiny static library in the
>> source, and has all the problems that come with it.
> ...
>> [M]y approach is similar to using an external shared library, with all the
>> benefits that come with it.
>
> We can also use a real shared library[1]. This has several benefits and
> one major drawback:
>
> Benefits:
> - No special code is required at the start of the game.
> - Other functionality is easier to add, such as using a highscore server
> (locally or on the net).
> - Highscore parsing code is taken out of the game to a central place,
> which allows us to really close the security hole of badly written games
> (as far as high score files are concerned).
>
> Drawback:
> - The current code that has already been written by the Fedora people is
> not usable, and must be replaced by calls into the library. In fact,
> this may mean significant rewriting work for each game.
>
> The benefits are nice, but the drawback is huge. I would like to agree
> the following about games with a central highscore file:
> - New games and games for which this is initially implemented should be
> written to use the shared library.
> - Games which already use their own system should be patched using the
> method Fedory uses.
> - It is considered an improvement, but not a priority, to patch games to
> use the shared library instead of their own handling, and thus to move
> from the sgid-safe patch to the shared library patch.
>

I like +1

> I've updated the wiki page on freedesktop.org about upstream to talk
> about this: http://www.freedesktop.org/wiki/Games/Upstream
> Please feel free to change it.

Ooh you've actually started a wiki page +1 for that too

> The library interface I am proposing there is:
> * Get the current list of highscores.
> * Register a callback to be notified of changes to a list of highscores.
> * Unregister the callback.
> * Free the list.
> * Send a new score, which is potentially a highscore. Returns: position
> in the high score list.

Did you check if we're not re-inventing the wheel here? IOW if there not
already is some generic highscore sharing server + client-lib somewhere
already ?

Regards,

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

On Fri, May 6, 2011 at 15:42, Hans de Goede <hdegoede@redhat.com> wrote:

> Did you check if we're not re-inventing the wheel here? IOW if there not
> already is some generic highscore sharing server + client-lib somewhere
> already ?

"server" as in "daemon"? That would be overkill, imo.


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

Hi,

On 05/06/2011 03:43 PM, Richard Hartmann wrote:
> On Fri, May 6, 2011 at 15:42, Hans de Goede<hdegoede@redhat.com> wrote:
>
>> Did you check if we're not re-inventing the wheel here? IOW if there not
>> already is some generic highscore sharing server + client-lib somewhere
>> already ?
>
> "server" as in "daemon"? That would be overkill, imo.

Not for the internet case it wouldn't and if such a thing already exists
it would be a good starting place, and we can extend it to support
local shared files with a sgid helper.

Regards,

Hans
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 
Old 05-06-2011, 06:35 PM
Michael Thomas
 
Default Standardizing various games packaging things across distros

On 05/06/2011 02:56 AM, Vitaly Magerya wrote:
>> Yes, in practice the discussed attack vector does not seem something
>> which often gets used / security bugs get filed for (*). Still I think
>> it would be good to agree on a way to best harden setgid games games,
>> esp. for the mentioned wiki page with advises for upstreams for games.
>
> If you'd ask me, "open file, drop privileges" is a sensible thing to do,
> and pushing such patches upstream is even better, because it will
> instantly offer increase in security for all the downstream users
> without any work on their part (even those who install programs manually
> will benefit).
>
> (Other security concerns, like an exploitable game being able to read
> and write all your home directory is more of a pressing matter though).

Perhaps a selinux policy could help here, at least for systems that have
selinux enabled.

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

Hi,

Op 06-05-11 15:42, Hans de Goede schreef:
> Did you check if we're not re-inventing the wheel here? IOW if there not
> already is some generic highscore sharing server + client-lib somewhere
> already ?

I didn't check. I'm usually reinventing the wheel. :-) That, and I
thought someone here would already know about it and yell if something
like this existed. :-)

A quick scan using google didn't give me any generic results, only some
for specific games.

Thanks,
Bas
_______________________________________________
games mailing list
games@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/games
 

Thread Tools




All times are GMT. The time now is 09:50 PM.

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