Bump to 0.7.1 please. :) * Fixed SUID security vulnerability by validating success of seteuid/setreuid, related security advisories, describing the vulnerability: * CVE-2006-2916 - artswrapper * CVE-2006-4447 - X.Org
*** Bug 140937 has been marked as a duplicate of this bug. ***
sound/gnome, please you provide an updated ebuild for this
I have a compilation error with dev-scheme/guile-1.8.1-r1, even with use deprecated discouraged. @scheme: any idea about that ?
(In reply to comment #3) > I have a compilation error with dev-scheme/guile-1.8.1-r1, even with use > deprecated discouraged. > @scheme: any idea about that ? without the actual error, all I can say is that maybe you need some other flags as well.
Here it is : if x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"BSESCM\" -I. -I. -I.. -I.. -I. -I.. -pthread -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DG_DISABLE_CONST_RETURNS -D_BIRNET_SOURCE_EXTENSIONS -march=athlon64 -O2 -pipe -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS -fno-cond-mismatch -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-cast-qual -Wno-pointer-sign -Wpointer-arith -Wredundant-decls -Wmissing-noreturn -ftracer -finline-functions -fno-keep-static-consts -MT bsescminterp.o -MD -MP -MF ".deps/bsescminterp.Tpo" -c -o bsescminterp.o bsescminterp.c; \ then mv -f ".deps/bsescminterp.Tpo" ".deps/bsescminterp.Po"; else rm -f ".deps/bsescminterp.Tpo"; exit 1; fi [lots of warnings] bsescminterp.c: In function 'signal_closure_marshal': bsescminterp.c:651: error: 'scm_catch_body_t' undeclared (first use in this function) bsescminterp.c:651: error: (Each undeclared identifier is reported only once bsescminterp.c:651: error: for each function it appears in.) bsescminterp.c:651: error: expected ')' before 'signal_marshal_sproc' bsescminterp.c:652: error: too few arguments to function 'scm_internal_cwdr' [again lots of warnings] this is in the "shell" subdirectory. [ebuild R ] dev-scheme/guile-1.8.1-r1 USE="deprecated discouraged elisp networking nls regex threads -debug -debug-freelist -debug-malloc" I really have no clue on how to fix that :/
the page http://beast.gtk.org/download seems to imply that guile-1.6 is needed.
ok, if upgrading doesnt work, we need to backport the patch. i had a quick look and this should do the job: http://svn.gnome.org/viewcvs/beast/trunk/launchers/suidmain.c?r1=2875&r2=4022&view=patch
thanks stefan for the help, but older version are unfortunately affected by bug #131751 (and most likely guile incompatibilities also) I've commited 0.7.1 to the tree, this one depends on guile 1.6*, so I've pmasked it to not cause up/downgrades of guile. in guile-1.8 ebuild there are those lines : # Guile seems to contain some slotting support, /usr/share/guile/ is slotted, but there are lots of collisions. Most in /usr/share/libguile. Therefore I'm slotting this in the same slot as guile-1.6* for now. SLOT="12" so perhaps if scheme wants to help there, by either taking care of the b0rkage that has caused guile bump or by slotting it properly... I've only pmasked beast 0.7.1, feel free to pmask older versions also as imho they are broken.
(In reply to comment #8) > so perhaps if scheme wants to help there, by either taking care of the b0rkage > that has caused guile bump or by slotting it properly... what borkage are you referring to that I could fix? I'd love to slot guile-1.8 separately, but I'm not sure it's possible.
> what borkage are you referring to that I could fix? I'd love to slot guile-1.8 > separately, but I'm not sure it's possible. bah I've not managed to compile beast with guile 1.8. Try it, it's in the tree under pmask, you're probably much more able than I am to deal with guile.
I've tried it. The beast developers have their work cut out for them I think.
fixes for beast to compile with guile-1.8 which will be included in the next release: http://bugzilla.gnome.org/show_bug.cgi?id=364464
Any news on this one?
Thanks marijn for the help here, beast 0.7.1 should be fine now, Adding arches as I suppose 0.7.1 will have to go stable and older versions will have to be removed.
Thx Alexis. Updating whiteboard.
TEST: test -x "/usr/bin/bsescm-0.7.1" Failed to verify installation of executable: /usr/bin/bsescm-0.7.1 make[1]: *** [check-installation] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-sound/beast-0.7.1/work/beast-0.7.1/shell' make: *** [check-recursive] Error 1 I assume the check should be disabled. [ebuild N ] media-sound/beast-0.7.1 USE="mad -debug -static"
Back to ebuild for now. Alexis please provide an updated ebuild.
very annoying beast ;) 26 Mar 2007; Alexis Ballier <aballier@gentoo.org> +files/beast-0.7.1-noinstalltest.patch, beast-0.7.1.ebuild: Dont test if files are installed as they are not at the time we run src_test
(In reply to comment #18) > very annoying beast ;) > > 26 Mar 2007; Alexis Ballier <aballier@gentoo.org> > +files/beast-0.7.1-noinstalltest.patch, beast-0.7.1.ebuild: > Dont test if files are installed as they are not at the time we run src_test So I cc arches again.
x86 stable
Thx Alexis and Christian for the quick response.
Created attachment 114669 [details] compile-failure on ppc Doesn't compile on ppc.
hmmm which linux-headers version do you have ? In which file is SIGTRAP defined ?
(In reply to comment #23) > hmmm which linux-headers version do you have ? =sys-kernel/linux-headers-2.6.17-r2 > In which file is SIGTRAP defined ? /usr/include/asm/signal.h
Ok I've been able to track and reproduce this error by compiling a cross toolchain and reading cpp output (ouch), it seems that there is a problem in glib headers : /usr/include/glib-2.0/glib/gbacktrace.h line 55 (glib 2.12.11): #else /* !__i386__ && !__alpha__ */ # define G_BREAKPOINT() G_STMT_START{ raise (SIGTRAP); }G_STMT_END #endif /* __i386__ */ but this file never includes signal.h on those non x86{,_64} nor alpha arches. while this could be fixed by including signal.h in any file using G_BREAKPOINT, I tend to think that's it's a glib bug. what do you think, should I just patch beast to resolve this security issue asap and then let the gnome team fix that or wait for a fix from the gnome team ?
Thx Alexis. Since this appears to be suid root I would prefer a fix asap and the let the gnome ppl fix their error afterwards.
then lets go : 30 Mar 2007; Alexis Ballier <aballier@gentoo.org> +files/beast-0.7.1-signalheader.patch, beast-0.7.1.ebuild: Include signal.h to workaround glib not including it causing compile failures on ppc
(In reply to comment #27) > then lets go : > 30 Mar 2007; Alexis Ballier <aballier@gentoo.org> > +files/beast-0.7.1-signalheader.patch, beast-0.7.1.ebuild: > Include signal.h to workaround glib not including it causing compile > failures on ppc Thanks, ppc stable.
I've never used BEAST but fail to see how you're going to escalate privileges unless you find another vulnerability in BEAST. hlieberman/Sound/gtk/Security do you know of any way of using this to gain root privileges without another vuln?
sound or gnome: could someone explain why this app need setuid? Is it really necessary? according to this: http://security.linuxtoday.com/developer/2004030900926NWGNRL It's just to get a -20 priority... I really don't see the point in doing this :/ Is it a kind of safety net to prevent jitters in case the box get overloaded? please advise.
I don't personally use beast; but I assume, based on past experience with people using sound systems like JACK, that it is setuid root so that it can set itself to SCHED_FIFO (or SCHED_RR). There are workarounds for those to not need root; maybe Gentoo already does it for JACK? If so, beast could be modified to use that, or maybe just configured to use it.
200704-22, thanks everybody. Sorry for the delay.
