A lot of selinux execstack denials in rawhide when starting audio apps

[Martin Sourada]

Hi,

I enabled SELinux for the first time and I got a lot of execstack
denials when starting applications providing audio output (so far I got
it with listen, rhythmbox, totem and gxine). I have new clean install
from latest rawhide live (plus some additional applications). Are these
worth filling bugs or are they false positives? I attach an output from
this denial for listen music player. I didn't do any actions to fix
these denials and the applications seem to work OK. I have SELinux
policy set to enforcing. If you need more info, ask. Not sure whether
this is for test or devel list so CC-ing devel.

Thanks,
Martin

[Jesse Keating]

On Sat, 29 Sep 2007 13:29:37 +0200
Martin Sourada <martin.sourada(a)seznam.cz&gt; wrote:

>  I enabled SELinux for the first time and I got a lot of execstack
>  denials when starting applications providing audio output (so far I
>  got it with listen, rhythmbox, totem and gxine). I have new clean
>  install from latest rawhide live (plus some additional applications).
>  Are these worth filling bugs or are they false positives? I attach an
>  output from this denial for listen music player. I didn't do any
>  actions to fix these denials and the applications seem to work OK. I
>  have SELinux policy set to enforcing. If you need more info, ask. Not
>  sure whether this is for test or devel list so CC-ing devel. 

Do you have codecs from fluendo installed?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Martin Sourada]

On Sat, 2007-09-29 at 16:35 +0200, Jesse Keating wrote:
>  On Sat, 29 Sep 2007 13:29:37 +0200
>  Martin Sourada <martin.sourada(a)seznam.cz&gt; wrote:
>  
>  > I enabled SELinux for the first time and I got a lot of execstack
>  > denials when starting applications providing audio output (so far I
>  > got it with listen, rhythmbox, totem and gxine). I have new clean
>  > install from latest rawhide live (plus some additional applications).
>  > Are these worth filling bugs or are they false positives? I attach an
>  > output from this denial for listen music player. I didn't do any
>  > actions to fix these denials and the applications seem to work OK. I
>  > have SELinux policy set to enforcing. If you need more info, ask. Not
>  > sure whether this is for test or devel list so CC-ing devel.
>  
>  
>  Do you have codecs from fluendo installed?
>   
No, from livna, but totem complains about missing codecs nevertheless...

Martin

[Jesse Keating]

On Sat, 29 Sep 2007 16:44:10 +0200
Martin Sourada <martin.sourada(a)seznam.cz&gt; wrote:

>  No, from livna, but totem complains about missing codecs
>  nevertheless... 
Well, could be the same thing.  If a codec ends up needing execmem due
to bad compile or whatever, it can cause your entire gstreamer stack to
need execmem, which would cause a lot of AVCs.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Martin Sourada]

On Sat, 2007-09-29 at 16:46 +0200, Jesse Keating wrote:
>  On Sat, 29 Sep 2007 16:44:10 +0200
>  Martin Sourada <martin.sourada(a)seznam.cz&gt; wrote:
>  
>  > No, from livna, but totem complains about missing codecs
>  > nevertheless...
>  
>  Well, could be the same thing.  If a codec ends up needing execmem due
>  to bad compile or whatever, it can cause your entire gstreamer stack to
>  need execmem, which would cause a lot of AVCs.
>   
It could, but the AVC denials appear just seconds (or less) after the
start, even if no media is opened - e.g. for totem it displays just
after the totem logo is displayed, for listen it displays even before
the main window is loaded...

Martin

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Sourada wrote:
>  It could, but the AVC denials appear just seconds (or less) after
> the
>  start, even if no media is opened - e.g. for totem it displays just
>  after the totem logo is displayed, for listen it displays even before
>  the main window is loaded... 
Plugins might be loaded anyway.

Since you said it's an execstack error it's easy enough to track down
and almost certainly is due to a compilation problem related to
assembler code.

It was python which was reported to have the problem.  So, go through
modules and see whether there is any requesting an executable stack.
For instance:

for f in /usr/lib/python2.5/lib-dynload/*.so; do echo $f; eu-readelf -l
$f|grep STACK; done

If any permission is other than "RW" you found a problem.  There are
likely more places with DSOs for python, I don't know enough about the
installation to say where they are.

If you want to go a more direct route, start totem (that was the program
with the problem?) under control of strace.  I.e., use

  strace -o somefile -f totem

and then sieve through the output in "somefile".  Search for open calls
of DSOs and then use eu-readelf as shown above on then.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG/ok12ijCOnn/RHQRArhwAKCfeguAJcDZtzgeHVKJjKJf9MDz/wCfalUf
> ToBrMppiNmetgY2w22xqVJ0=
> =EU48
> -----END PGP SIGNATURE-----

[Martin Sourada]

On Sat, 2007-09-29 at 19:19 +0200, Ulrich Drepper wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Martin Sourada wrote:
>  > It could, but the AVC denials appear just seconds (or less) after the
>  > start, even if no media is opened - e.g. for totem it displays just
>  > after the totem logo is displayed, for listen it displays even before
>  > the main window is loaded...
>  
>  Plugins might be loaded anyway.
>  
>  Since you said it's an execstack error it's easy enough to track down
>  and almost certainly is due to a compilation problem related to
>  assembler code.
>  
>  It was python which was reported to have the problem.  So, go through
>  modules and see whether there is any requesting an executable stack.
>  For instance:
>  
>  for f in /usr/lib/python2.5/lib-dynload/*.so; do echo $f; eu-readelf -l
>  $f|grep STACK; done
>  
>  If any permission is other than "RW" you found a problem.  There are
>  likely more places with DSOs for python, I don't know enough about the
>  installation to say where they are.
>  
>  If you want to go a more direct route, start totem (that was the program
>  with the problem?) under control of strace.  I.e., use
>  
>    strace -o somefile -f totem
>  
>  and then sieve through the output in "somefile".  Search for open calls
>  of DSOs and then use eu-readelf as shown above on then.
>  
>  - --
>  ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.7 (GNU/Linux)
> >  
> >  iD8DBQFG/ok12ijCOnn/RHQRArhwAKCfeguAJcDZtzgeHVKJjKJf9MDz/wCfalUf
> >  ToBrMppiNmetgY2w22xqVJ0=
> >  =EU48
> >  -----END PGP SIGNATURE----- 
>   
The python denial is from listen, but other applications is having this
problem too, I noticed it in totem (with gstreamer backend) and gxine
(uses xine-lib) as well. One thing that is same for all the apps I am
getting this with is audio output, so I thought it could be
pulseaudio... The suggestion you gave me for python showed only RW
permissions. Will try strace as well (need to install it first).

[Martin Sourada]

OK, for some strange reason I cannot replicate the SELinux denial when
totem starts, but when running it with strace and opening a concrete
file it shows where problem might lie, unfortunately it's from livna:

(totem:12184): GStreamer-WARNING **: Failed to load plugin
'/usr/lib/gstreamer-0.10/libgstffmpeg.so': libx264.so.56: cannot enable
executable stack as shared object requires: Permission denied

For gxine it seems that x264 is also the core of the problem. If someone
can confirm this, I'll file a bug in livna against x264.

Thanks,
Martin

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Sourada wrote:
>  (totem:12184): GStreamer-WARNING **: Failed to load plugin
>  '/usr/lib/gstreamer-0.10/libgstffmpeg.so': libx264.so.56: cannot enable
>  executable stack as shared object requires: Permission denied
>  
>  For gxine it seems that x264 is also the core of the problem. If someone
>  can confirm this, I'll file a bug in livna against x264. 
No need to wait.  Look at the file

  eu-readelf -l /path/to/libx264.so.56

If there is no GNU_STACK line or the permission is RWE then file a bug.
 This should not be necessary.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG/xeC2ijCOnn/RHQRAvUbAJ45x6WqYyVXFKxcA+aSZySSdv6AXACgzhA/
> 0c88NhY9QKfyB7+Xwjb/Ouw=
> =3nUd
> -----END PGP SIGNATURE-----

[Martin Sourada]

On Sun, 2007-09-30 at 05:26 +0200, Ulrich Drepper wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Martin Sourada wrote:
>  > (totem:12184): GStreamer-WARNING **: Failed to load plugin
>  > '/usr/lib/gstreamer-0.10/libgstffmpeg.so': libx264.so.56: cannot enable
>  > executable stack as shared object requires: Permission denied
>  > 
>  > For gxine it seems that x264 is also the core of the problem. If someone
>  > can confirm this, I'll file a bug in livna against x264.
>  
>  No need to wait.  Look at the file
>  
>    eu-readelf -l /path/to/libx264.so.56
>  
>  If there is no GNU_STACK line or the permission is RWE then file a bug.
>   This should not be necessary.
>  
>  - --
>  ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.7 (GNU/Linux)
> >  
> >  iD8DBQFG/xeC2ijCOnn/RHQRAvUbAJ45x6WqYyVXFKxcA+aSZySSdv6AXACgzhA/
> >  0c88NhY9QKfyB7+Xwjb/Ouw=
> >  =3nUd
> >  -----END PGP SIGNATURE----- 
>   
Thanks again, it has GNU_STACK with RWE permissions... As far as the bug
goes, Hans was faster then me and included a patch [1].

Thanks,
Martin

References:
[1] http://bugzilla.livna.org/show_bug.cgi?id=1659