Bug 467033 - SELinux is preventing amarok from changing a writable memory segment executable.
SELinux is preventing amarok from changing a writable memory segment executable.
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: amarok (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Aurelien Bompard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-15 07:22 EDT by cgrim
Modified: 2008-10-15 15:07 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-15 14:45:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description cgrim 2008-10-15 07:22:17 EDT
Description of problem:
The amarok application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests web page explains how to remove this requirement. If amarok does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed.

Version-Release number of selected component (if applicable):
Name       : amarok
Arch       : x86_64
Version    : 1.92
Release    : 2.fc10

How reproducible:
SELinux confihured like this:
System Default Enforcing Mode = Enforcing
Current Enforcing Mode = Enforcing
System Default Policy Type = Targeted

Steps to Reproduce:
1. Enable SELinux as it's shown above
2. Login into the Gnome desktop
3. Run Amarok
  
Actual results:
Amarok did not start and SELinux TroubleShooter shows this message: SELinux is preventing amarok from changing a writable memory segment executable. 

Expected results:
Amarok starts correctly.

Additional info:
Now I'm using this workaround:
chcon -t unconfined_execmem_exec_t '/usr/bin/amarok'
Comment 1 Rex Dieter 2008-10-15 07:38:15 EDT
I cannot reproduce (on F-9 anyway, I'll test F-10 tonight).

Do you have any 3rd party codecs installed?  
Which phonon backend are you using? (xine-lib is the default, if you haven't modified/configured anything).
Comment 2 cgrim 2008-10-15 08:02:26 EDT
As you I didn't have this problem in F-9. It appeared after upgrade on F-10 (now I have everything updated on the newest versions - SELinux, Amarok).

I have installed:
amarok.x86_64                            1.92-2.fc10       
amarok-extras-freeworld.noarch           1.4.8-3.fc10 (from RPMFusion)
phonon-backend-xine.x86_64               4.1.2-3.fc10      
xine-lib.x86_64                          1.1.15-1.fc10.1
xine-lib-extras.x86_64                   1.1.15-1.fc10.1
xine-lib-extras-freeworld.x86_64         1.1.15-4.fc10 (from RPMFusion)

So I use xine as phonon backend.
Comment 3 Rex Dieter 2008-10-15 08:10:20 EDT
Thanks, in the meantime, can you to see if this is reproducible without xine-lib-extras-freeworld installed?

Dan (cc'd), any obvious gotchas wrt F-9/F-10 differences that would affect xine-lib here?
Comment 4 cgrim 2008-10-15 08:25:31 EDT
I removed xine-lib-extras-freeworld (and it removed amarok-extras-freeworld) and the problem is still here.


I tied to set global boolean allow_execmem in SELinux Management on true and after that SELinux TroubleSooter showed me another problem with Amarok:

Summary: SELinux is preventing amarok from making the program stack executable.
Description: The amarok application attempted to make its stack executable. This is a potential security problem. This should never ever be necessary. Stack memory is not executable on most OSes these days and this will not change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests web page explains how to remove this requirement. If amarok does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report against this package.


It seems like the change was done in SELinux, and now it discovers more security problems, which probably were already in F-9,F-8,F-7,... but undiscovered?
Comment 5 Daniel Walsh 2008-10-15 09:28:10 EDT
The difference is I changed the defaults for the 

allow_execmem and allow_execstack booleans to false.  This will cause any app that is not labeled to need executable stack or memory to fail.

Java and Mono type apps need this, and need to be labeled correctly.  Other apps use optimizations that require it.

http://people.redhat.com/~drepper/selinux-mem.html

My goal is to keep this booleans turned off for F10 to increase SELinux protection for the uncofined user.
Comment 6 Gwyn Ciesla 2008-10-15 10:38:04 EDT
(In reply to comment #5)
> The difference is I changed the defaults for the 
> 
> allow_execmem and allow_execstack booleans to false.  This will cause any app
> that is not labeled to need executable stack or memory to fail.
> 
> Java and Mono type apps need this, and need to be labeled correctly.  Other
> apps use optimizations that require it.
> 
> http://people.redhat.com/~drepper/selinux-mem.html
> 
> My goal is to keep this booleans turned off for F10 to increase SELinux
> protection for the uncofined user.

I have https://bugzilla.redhat.com/show_bug.cgi?id=467054.

Is it acceptable to 

chcon -t unconfined_execmem_exec_t '/usr/bin/nexuiz-sdl'

in %post as a workaround until I can patch?  http://people.redhat.com/drepper/selinux-mem.html makes it look like we need to use mmap instead of malloc in nexuiz.  Will that suffice?
Comment 7 Ulrich Drepper 2008-10-15 10:52:09 EDT
(In reply to comment #6)
> http://people.redhat.com/drepper/selinux-mem.html makes it look like we need to
> use mmap instead of malloc in nexuiz.  Will that suffice?

I don't know the details but if the problem is that you're trying to execute something you've written into memory allocated using malloc, then, yes, using mmap (the double mapping) should work fine.
Comment 8 Rex Dieter 2008-10-15 10:54:20 EDT
cgrim, you sure you don't have any other 3rd-party xine codecs installed? (say
in /usr/lib/codecs?)
Comment 9 Kevin Kofler 2008-10-15 11:09:36 EDT
Is there any way of obtaining a backtrace of the offecting mprotect call?
Comment 10 cgrim 2008-10-15 13:22:42 EDT
(In reply to comment #8)
> cgrim, you sure you don't have any other 3rd-party xine codecs installed? (say
> in /usr/lib/codecs?)

/usr/lib/codecs doesn't exist and /usr/lib64/codecs is empty. I have installed some another codecs: ffmpeg, ffmpeg-libs, libquicktime, mencoder, mjpegtools-libs, x264-libs.

I have the same/similar problem with these another applications: vlc, mplayer, kino, avidemux, glxinfo, quake3, googleEarth, opera, skype.

It seems, that the problem is only with multimedia apps.

I set allow_execmem, allow_execmod and allow_execstack booleans on true to be able to use these applications. But if you want another tests from me, I can revert it back to false - no problem ;-)
Comment 11 cgrim 2008-10-15 14:19:31 EDT
Why I didn't try to run amarok from shell at first? :-(

[cgrim@cml ~]$ amarok
amarok: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied

It seems, that problem is in nvidia drivers?
Comment 12 Rex Dieter 2008-10-15 14:45:35 EDT
if you have those installed, yes.

I *did* if you had any 3rd party stuff.

Marking CANTFIX (it's nvidia's problem) (unless you can reproduce on a clean fedora box). :)
Comment 13 Daniel Walsh 2008-10-15 15:07:53 EDT
cgrim your original fix is fine.

Note You need to log in before you can comment on or make changes to this bug.