Like many roguelikes, it has a shared high score file and Bones files that all users are meant to have their scores and final data written to. As a result, the game is forced to run setgid games so that it has the rights to write to /var/games/ivan/. While packaging this application, I got a lot of help from some of the Fedora-KDE guys (hi Kevin, Ben) and they both suggested I run this through Fedora Security SIG so that the game would properly demote itself to non-setgid when it doesn't need to. What is the proper channel to go about this? Should I just mail to the security list? Should I put this package up for review beforehand/in the meantime?

Andrea Musuruane wrote: > On Mon, Aug 31, 2009 at 7:55 AM, Ryan Rix<phrkonaleash(a)gmail.com> wrote: >> Like many roguelikes, it has a shared high score file and Bones files >> that all users are meant to have their scores and final data written to. >> As a result, the game is forced to run setgid games so that it has the >> rights to write to /var/games/ivan/. While packaging this application, I >> got a lot of help from some of the Fedora-KDE guys (hi Kevin, Ben) and >> they both suggested I run this through Fedora Security SIG so that the >> game would properly demote itself to non-setgid when it doesn't need to. >> >> What is the proper channel to go about this? Should I just mail to the >> security list? Should I put this package up for review beforehand/in the >> meantime? > > The game must drop setuid as early as possible: > http://fedoraproject.org/wiki/SIGs/Games/Packaging > > If you need help, consider writing to the fedora-games-list: > http://www.redhat.com/mailman/listinfo/fedora-games-list I didn't think of this when I first wrote my post but now am realizing that the application creates Bones files when a player dies in /var/games/ivan... :( How would I apply setgid rules to this scenario? I cannot accurately predict the name of the bones file in the main() and cannot create a new file every single time the application starts up, so I am unsure of how to handle that. Suggestions?

Hans de Goede wrote: > > This is a known issue with roguelikes, we've solved this for the other > roguelikes (see there spec files) by creating a group esp. for the game > and making it sgid itsowngroup and never dropping the sgid rights. This > way we strongly limit the amount of damage / attacks which can be done by > not dropping sgid, this is the best security versus usability trade off we > could come up with for rogue likes. > > Regards, > > Hans Looking at the specs for nethack, ularn and rogue (cvs.fedoraproject.org/viewvc) shows that these are simply setgid games. I did not look at the actual code to see how they handle setgid.

Hans de Goede wrote: > which is why they are given there own group to limit any > potential fall out from privilege escalation bugs in their code. Im misinterpreted this statement then, sorry :) I understood it as each game ran in the context of group nethack, or group rogue, but not group games. I understand this now. This makes more sense and is currently how my spec is written, the game runs in the context of setgid games.