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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/games
