Bug 523959

Summary: setroubleshoot: SELinux is preventing /usr/lib/firefox-3.5.3/firefox from changing a writable memory segment executable.
Product: [Fedora] Fedora Reporter: Yingbo Qiu <qiuyingbo>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: ardillon.42, dwalsh, jistone, jkubin, lorisdianna, mgrepl, nigel
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:c40bfbb21c9a3ace6ef6d4116651bdc0038561f57fe5121b418b0fe7e654a107
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-20 21:06:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yingbo Qiu 2009-09-17 12:27:57 UTC
The following was filed automatically by setroubleshoot:

Summary:

SELinux is preventing /usr/lib/firefox-3.5.3/firefox from changing a writable
memory segment executable.

Detailed Description:

The firefox 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
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. If firefox 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.

Allowing Access:

If you trust firefox to run correctly, you can change the context of the
executable to execmem_exec_t. "chcon -t execmem_exec_t
'/usr/lib/firefox-3.5.3/firefox'". You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'"

Fix Command:

chcon -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                None [ process ]
Source                        mutter
Source Path                   /usr/bin/mutter
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           firefox-3.5.3-1.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.31-5.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmem
Host Name                     (removed)
Platform                      Linux (removed) 2.6.31-14.fc12.i686 #1 SMP Tue Sep
                              15 04:04:35 EDT 2009 i686 i686
Alert Count                   45
First Seen                    Sat 12 Sep 2009 06:49:32 PM CST
Last Seen                     Thu 17 Sep 2009 08:24:38 PM CST
Local ID                      c2d2ccc9-36c4-4a1e-9e81-a855c650000d
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1253190278.880:25): avc:  denied  { execmem } for  pid=1871 comm="firefox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

node=(removed) type=SYSCALL msg=audit(1253190278.880:25): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=2000 a2=7 a3=22 items=0 ppid=1856 pid=1871 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="firefox" exe="/usr/lib/firefox-3.5.3/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)


audit2allow suggests:

#============= unconfined_t ==============
allow unconfined_t self:process execmem;

Comment 1 Daniel Walsh 2009-09-17 19:22:14 UTC
Added a new plugin that will tell you the following.

The firefox application attempted to change the access protection of memory
(e.g., allocated using malloc). This is a potential security problem. Firefox is
probably not the problem here ,but one of its plugins. You could remove the
plugin and the app would no longer require the access. If you figure out which
plugin is causing the access request, please open a bug report on the plugin.

Allowing Access:

There are two ways to fix this problem, you can install the nsspluginwrapper
package, which will cause firefox to run its plugins under a separate process.
This process will allow the execmem access. This is the safest choice. You could
also turn off the allow_unconfined_nsplugin_transition boolean.
setsebool -P allow_unconfined_nsplugin_transition=0

Fix Command:

yum install nspluginwrapper


BTW DO YOU HAVE FLASHPLUGIN installed or any other random plugin installed.

Comment 2 Josh Stone 2009-09-26 22:28:24 UTC
I'm also having this problem.  While Daniel's suggestion does fix it, I don't the problem really lies in any plugin, even though I do have the flashplugin installed.  Here's the sequence of what I tried that makes me think this:

# yum install nspluginwrapper
# setsebool -P allow_unconfined_nsplugin_transition=0
OK, good, things still work here.

# yum remove nspluginwrapper
Firefox still works!  Hmm...

# setsebool -P allow_unconfined_nsplugin_transition=1
Ah, now Firefox breaks again.  Let's try something else.

$ firefox -safe-mode
Works fine!

(disable all addons & plugins)
Firefox doesn't work.  Seems wrong to blame the plugins now...

Add to prefs.js: user_pref("javascript.options.jit.content", false);
It works!

(enable all addons & plugins)
It works!

So, it seems to me that the true culprit is the javascript JIT.  Either turning off that sebool or disabling the JIT will both solve the problem, but I'm curious what has changed to make this a problem...

Comment 3 Josh Stone 2009-09-29 05:57:37 UTC
I take it back -- the JIT seemed to be the problem, but I've since gotten other errors that seem to indicate that the nsplugin stuff is still needed.  Sorry for the noise...

Comment 4 Daniel Walsh 2009-10-20 21:06:10 UTC
522606Fixed in selinux-policy-3.6.32-29.fc12.noarch