[Bug 469585] Review Request: moon-buggy - Drive and jump with some kind of car across the moon

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=469585





--- Comment #20 from Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>  2009-01-04 09:36:30 EDT ---
(In reply to comment #19)
> Interesting. Which Fedora release and which RPM version? I've _no_ issues to
> rebuild or install this package on plain Fedora 10 and CentOS 5. Maybe we can
> get out, what's broken here (btw, rpm2cpio <src> | cpio -idm would have also
> worked).

Both on my rawhide i386 system and koji scratch build
fails (ref:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1031143 )

> Danger is everywhere. You could exploit vi(1) with nice stuff, insert and
> execute your own malicious code written in the file, vi is going to read and
> edit - 

I guess vi case does not apply for the case in this package.
What I am saying is that the malicious code inserted by _one_ person
is read by _another_ person unintentionally (i.e. like
the case in which some malicious png file created by unknown
person on the internet is accessed by local users). 
For /bin/vi case, the impact of the risk should be limited 
to the person who intentionally tried to read the file.

> AFAIK this even was recently possible and is now fixed there. For me
> this example is the same situation as what you try to describe above, but for
> software like vi this seems much more dangerous to me rather to moon-buggy.

So I don't think vi and moon-buggy are the same situation.

> There is always some risk once more than a single user is able to touch a
> file. Yesterday evening when enabling that feature I already had some kind
> of IRC discussion on #fedora-devel. But removing the highscore feature isn't
> acceptable for me at all.

Then please do this in the safe way. By the way the basic problem
I think is that the file "mbscore" is created by arbitrary person.

> My C knowledge isn't the best, but when reading read_version2_data() or the
> read_version3_data() from highscore.c, the C code seems to be good. On the
> other hand, there AFAIK was no CVE report for that possible issue ever, even 
> many various Linux distributions deliver(ed) moon-buggy to their users. So
> why should I feel not good for Fedora here?

Because Fedora is more careful? (actually security responsible
team on RedHat is very concerned about setuid/setgid binaries:
e.g.
https://www.redhat.com/archives/fedora-security-list/2007-April/msg00004.html )


> [20:32:08] < rsc> Packagers around? I've got a game which would like to write a
> multiuser highscore file. Where? /var/games/%{name}/*? And which permissions?
> Program offers setgid with games user.
> [20:32:22] < ixs> why not?
> [20:32:39] < ixs> but I'd give it a special user...
> [20:32:42] < ixs> for security reasons
> [20:32:56] < ixs> or simple remove the highscore feature
> [20:33:08] < rsc> ixs: wäh!
> [20:33:18] < ixs> :>
> [20:34:30] < lkundrak> ixs: yes, rsc is right
> [20:34:53] < ixs> ahh come on
> [20:34:57] < ixs> nobody needs highscores
> [20:34:58] < ixs> amirite?
> [20:35:54] < lkundrak> ixs: i suggest looking at some already existing game.
> probably nethack or something like that
> [20:37:11] < ivazquez> Using games should be fine. What are they going to do,
> overwrite other games' high scores? :P
> [20:37:35] < rsc> lkundrak: existing games are doing what the program offers
> (setgit + /var/games/)
> [20:37:51] < rsc> lkundrak: at least one, I was pointed to.
> [20:38:43] < ivazquez> nethack and Maelstrom both use the games group.
> [20:40:14] < rsc> ivazquez: /var/games/%{name}.highscore or
> /var/games/%{name}/highscore or what would you suggest?
> [20:44:53] < ivazquez> I would put it in its own directory.
> [20:45:19] < ivazquez> I would consider /var/games to be a games-specific
> /var/lib.
> [20:47:43] < rsc> ivazquez: thanks

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.