Rawhide updates to Manaworld and WorldFogre stuff
by Bruno Wolff III
I have manaworld updated to the latest upstream release.
I have all of the worldforge related packages updated to the lastest release
(trunk for sear, though it looks like there may be a new release soon) but
not adequatetly tested as 3d isn't working well for me in rawhide right now.
I'd be interested in feedback for how ember and sear work on other hardware
from other rawhide users. I'll be making a live image soon so that I can
test on some more modern hardware.
I'll be trying to keep the WorldForge stuff more up to date. cyphesis also
should get some attention related to running it as a service in Fedora.
The outlook for getting these changes into F15 is murky. At the very least
I'd want to make sure that packages using Ogre 1.7.3 all appear to work
on some hardware.
13 years
IMPORTANT - Fedora Project Contributor Agreement Signing Window Is Open
by Tom Callaway
Please take a moment and read this brief email, as it is important.
Fedora is in the process of retiring our old "Individual Contributor
License Agreement" (also known as the ICLA or CLA) and replacing it with
the new Fedora Project Contributor Agreement (FPCA).
All Fedora contributors with accounts in the Fedora Account System
(https://admin.fedoraproject.org/accounts) who have agreed to the old
CLA *MUST* agree to the new FPCA by June 17, 2011 to continue
contributing to Fedora.
Here is how you do this:
1) Login to the Fedora Account System:
https://admin.fedoraproject.org/accounts
2) Once logged in, click on the "My Account" link in the blue box on the
left side of the window.
3) On the page that loads, you will see a section labeled "Account
Details". Look for the line that says "Contributor Agreement". On that
line, you should see a new section that says:
"New CLA Not Signed - We need contributors to sign the new Contributor
Agreement(Complete it now!)"
Click on "Complete it now!" and follow the prompts.
*****
It is important that Fedora Account holders who have signed the old
Fedora CLA sign the new FPCA. We have allotted a window of one month for
Fedora contributors to agree to the FPCA. This means that after June 17,
2011, any Fedora Contributors who have not agreed to the FPCA will have
their "cla_done" flag set to False. This also means that any groups that
they are in which are dependent upon "cla_done", such as "packager",
"ambassador", and Fedora People access will be removed.
There are a few accounts which are exempt from this, specifically,
accounts which are members of the "cla_dell", "cla_intel", and
"cla_redhat" groups. If you do not know what these groups are, you are
probably not in them. :) Accounts in these groups will not see the "New
CLA Not Signed" line on their "My Account" page, and do not need to take
any action at this time.
Please take a minute and login to FAS to agree to the terms of the FPCA,
to avoid loss of access.
More information about the FPCA, including the final FPCA text, can be
found here:
https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
If you have any additional questions about the FPCA or the re-signing
process, please feel free to email me directly at legal(a)fedoraproject.org.
Thanks,
Tom Callaway, Fedora Legal
==
Fedora Project
13 years, 1 month
Access to some of Alexey Torkhov's packages
by Bruno Wolff III
Alexey hasn't been doing a lot of Fedora related stuff recently. I was able
to reach him indirectly a few months ago to get access to some of his
packages that depend on ogre. But more recently I have been trying to get
access to some of his other game related packages in advance of issues,
so that I could work on them in a more timely fashion. However there was
no response to my email messages noting the I requested access in the
package database system. For a few other packages I was able to have
another co-maintainer give me access but for the following packages
Alexey is the only one that can approve access by the normal means:
boswars-addons, btanks, gnubik and kcheckers.
gnubik currently needs to be fixed in rawhide for the guile update and there
is a new upstream version available. The others I wasn't in a special hurry
to touch write now.
13 years, 1 month
Re: Standardizing various games packaging things across distros
by Hans de Goede
Hi,
On 05/09/2011 02:08 AM, Richard Hartmann wrote:
> FYI, it seems extremely likely that any and all games directories will
> be deprecated in the new release of the FHS. In case you _disagree_,
> it's time to hit the FHS mailing list.
Interesting, what is to happen with /var/games ?
And what do we want to happen with /var/games ?
Also wrt /var/games, from my pov it is not worth the effort to
mv highscore files for existing games from there to
/var/lib/games (or the other way around). This will require
always fragile pre/post install scripts for very little gain,
so my proposal is to leave the location of global highscore
files unchanged for existing packages.
Regards,
Hans
13 years, 1 month
Re: Standardizing various games packaging things across distros
by Bas Wijnen
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
13 years, 1 month
Re: Standardizing various games packaging things across distros
by Hans de Goede
Hi,
On 05/05/2011 11:20 AM, Vitaly Magerya wrote:
> Jon Dowland wrote:
>> I'd like to hear from some other distros to see who else does what before
>> considering such a move.
>
> FWIW, the common practice on FreeBSD is to place game binaries into
> /usr/local/bin, static game data into /usr/local/share/<gamename>, and
> variable game data into /var/games/<gamename>. There are some
> exceptions, but this is how most ports work.
Interesting if you s@/usr/local@/usr@ FreeBSD is doing the exact
same thing as Fedora.
> As for /var data permissions, setgid binaries with group "games" are
> common (/var/games is owned by root:games); I don't think there's any
> effort to improve security above whatever the upstream offers.
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.
*) Likely because there is lower hanging fruit for blackhats to abuse.
Regards,
Hans
13 years, 1 month
Re: Standardizing various games packaging things across distros
by Hans de Goede
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
13 years, 1 month
Standardizing various games packaging things across distros
by Hans de Goede
Hi All,
Recently the thought has popped up in my head more then once, that it would
be good to standardize various game packaging related things between
distros, so that we can send a consistent message to upstreams hiow
we would like to see various game related things handled.
I've made a list of points which I would like us to come to some
start of standard for below:
1) /usr/bin versus /usr/games
Some games get installed into /usr/bin, others into /usr/games,
in Fedora we've standardized on just putting all game executables
into /usr/bin, since /usr/games is not in the default PATH and
thus breaks starting the games from the cmdline
Note that the FHS thus contain /usr/games, but lists it as
optional (together with illustrious things such as /usr/X11R6).
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.
3) /var/games versus /var/lib/games
FHS: /var/games Variable game data (optional)
To me this is the one case where having a separate dir for games
makes sense for global highscore right management, just like we
also have a default gid for games, for sgid games. In Fedora we
we (the Games SIG) have chosen to standardize on /var/games,
which I must admit as I write this is a bit inconsistent,
since we did choose not to use the other 2 optional games
dirs from the FHS.
Some games by default use /var/lib/games instead of /var/games,
all gnome games do this for example. From one pov this is somewhat
consistent with the not using of any optional games subdirs
from the FHS (gnome does not use /usr/games nor /usr/share/games),
from another pov this is just having a special games dir under
/var in a different place then the one advised by the FHS.
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
This is in all honesty not a very likely / easy scenario, and likely
the attacker will choose a different attack vector to its intended
target. Still it is something to keep in mind. There is little we
can do to avoid the 2a scenario, other then audit the highscore
table loading code, and hope we catch all bugs.
The 2b scenario however can be fixed. The usual approach with
elevated rights binaries, with a longer then do one thing and exit
lifetime, is to do the things for which the elevated rights are
needed asap after startup and drop all rights. Many games however
don't do this.
The Fedora Games SIG is advocating (and has patches for) handling
global highscore files the following way:
1) open the global highscore file r+ as first thing in main, with a
fully hardcoded path
2) drop all special rights
3) keep the highscore file open until the program exits, and rather
then doing fopen / fclose use rewind and fflush.
Doing things this way limits what an attacker can do when it
subverts a game with global highscore support to corrupting the
one highscore file, instead of being able to do anything made
possible by the gid games rights...
We've been patching games to work this way for a while now, and
this works for 95% of them (the one exception being rogue likes
(*) with their bones files, etc.). Most upstreams have pretty poor
practices here, we've encountered the following variants:
1) no rights handling at all
2) seteuid / setegid tricks, which offer almost no protection,
since the attacker can simply do a seteuid itself to get
the elevated rights again
Regards,
Hans
*) In Fedora we've chosen to create a new gid for each rogue
like, and making its /var dir writeable by that gid, thus limiting
the damage which can be done when it is subverted to only writing
files in that dir.
13 years, 1 month
Re: Standardizing various games packaging things across distros
by Hans de Goede
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
13 years, 1 month
