Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 597617 - SELinux is preventing /usr/lib64/firefox-3.6/firefox from making the program stack executable.
Summary: SELinux is preventing /usr/lib64/firefox-3.6/firefox from making the program ...
Status: CLOSED DUPLICATE of bug 572791
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:a95ca13042a...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-29 19:58 UTC by Gene Snider
Modified: 2011-05-05 03:33 UTC (History)
90 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-09 13:26:32 UTC

Attachments (Terms of Use)

Description Gene Snider 2010-05-29 19:58:00 UTC

SELinux is preventing /usr/lib64/firefox-3.6/firefox from making the program
stack executable.

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

The firefox 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 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.

Allowing Access:

Sometimes a library is accidentally marked with the execstack flag, if you find
a library with this flag you can clear it with the execstack -c LIBRARY_PATH.
Then retry your application. If the app continues to not work, you can turn the
flag back on with execstack -s LIBRARY_PATH. Otherwise, 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/lib64/firefox-3.6/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

Fix Command:

chcon -t execmem_exec_t '/usr/lib64/firefox-3.6/firefox'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
Target Objects                None [ process ]
Source                        firefox
Source Path                   /usr/lib64/firefox-3.6/firefox
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           firefox-3.6.3-4.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.8.1-3.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Plugin Name                   allow_execstack
Host Name                     (removed)
Platform                      Linux Mobile-PC 2.6.34-11.fc14.x86_64 #1 SMP Sat
                              May 22 01:03:52 UTC 2010 x86_64 x86_64
Alert Count                   2
First Seen                    Sat 29 May 2010 11:53:11 AM PDT
Last Seen                     Sat 29 May 2010 11:53:11 AM PDT
Local ID                      c87fb89b-4ed9-4d9c-aefe-09d1a5565bdf
Line Numbers                  

Raw Audit Messages            

node=Mobile-PC type=AVC msg=audit(1275159191.763:19543): avc:  denied  { execstack } for  pid=7709 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=Mobile-PC type=AVC msg=audit(1275159191.763:19543): avc:  denied  { execmem } for  pid=7709 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=Mobile-PC type=SYSCALL msg=audit(1275159191.763:19543): arch=c000003e syscall=10 success=yes exit=0 a0=7fff7761a000 a1=1000 a2=1000007 a3=380681b534 items=0 ppid=7695 pid=7709 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/lib64/firefox-3.6/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  allow_execstack,firefox,unconfined_t,unconfined_t,process,execstack
audit2allow suggests:

Comment 1 Daniel Walsh 2010-06-01 13:39:26 UTC
You can turn on the allow_execstack boolean to get rid of the avc.

Do you have any plugins installed that could be causing this?

Comment 2 Gene Snider 2010-06-01 22:31:18 UTC
Not that I'm aware of.  I used to get this when I used the 32 bit flash plugin and nspluginwrapper.  I switched to Leigh's 64 bit flash plugin and removed nspluginwrapper months ago.  This denial disappeared after that in F12, F13, and F14 until this bug report was filed.  I'll try FF in another user with no plugins to see if that makes a difference.


Comment 3 Gene Snider 2010-06-02 00:14:08 UTC
I did some research, and this error and another one from Firefox both started immediately after the following update:

May 29 11:25:40 Updated: openldap-2.4.22-2.fc14.x86_64
May 29 11:25:41 Updated: ibus-libs-1.3.4-2.fc14.x86_64
May 29 11:26:01 Updated: ibus-1.3.4-2.fc14.x86_64
May 29 11:26:01 Updated: ibus-gtk-1.3.4-2.fc14.x86_64
May 29 11:26:18 Updated: 2:vim-common-7.2.440-1.fc14.x86_64
May 29 11:26:21 Installed: 12:aspell-0.60.6-12.fc14.x86_64
May 29 11:26:22 Updated: gjs-0.7-1.fc14.x86_64
May 29 11:26:31 Updated: mutter-2.31.2-2.fc14.x86_64
May 29 11:26:31 Updated: 1:pkgconfig-0.25-1.fc14.x86_64
May 29 11:26:32 Updated: libdrm-2.4.21-0.1.fc14.x86_64
May 29 11:26:40 Updated: gnome-shell-2.31.2-2.fc14.x86_64
May 29 11:26:42 Updated: link-grammar-4.6.7-3.fc14.x86_64
May 29 11:26:43 Updated: 2:vim-enhanced-7.2.440-1.fc14.x86_64
May 29 11:26:44 Updated: nfs-utils-lib-1.1.5-2.fc14.x86_64
May 29 11:26:45 Updated: linux-atm-libs-2.5.1-1.fc14.x86_64
May 29 11:26:46 Updated: 2:vim-minimal-7.2.440-1.fc14.x86_64
May 29 11:26:49 Updated: webkitgtk-1.3.1-1.fc14.x86_64
May 29 11:26:53 Updated: mousetweaks-2.31.2-1.fc14.x86_64
May 29 11:27:23 Updated: selinux-policy-3.8.1-3.fc14.noarch
May 29 11:28:24 Updated: selinux-policy-targeted-3.8.1-3.fc14.noarch
May 29 11:28:25 Updated: libdrm-devel-2.4.21-0.1.fc14.x86_64
May 29 11:28:29 Updated: openldap-devel-2.4.22-2.fc14.x86_64
May 29 11:28:35 Updated: orca-2.31.2-1.fc14.x86_64
May 29 11:28:36 Updated: gnome-icon-theme-extras-2.30.1-2.fc14.noarch

I assumed that they were related to the selinux-policy* updates.


Comment 4 Bug Zapper 2010-07-30 11:45:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 5 Gene Snider 2010-09-01 01:09:43 UTC
I know there's been a lot of progress on this AVC denial, both at Fedora and upstream.  It completely disappeared (I thought) around the time F14 branched.  However, it is still possible to generate this denial consistently by clicking on the "Verify Java version" button at


Comment 6 Daniel Walsh 2010-09-01 13:07:27 UTC
Gene the problem is the jave plugin is being executed within the firefox program causing execstack access to be required.  Using the fedora java plugin firefox executes the java program as a separate process.  So we can allow firefox to run without execstack privs and only allow java apps to have that priv.  With the oracle java  plugin we have to allow the firefox program execstack which really means we might as well turn off the check.  Unless Oracle java plugin goes back to execing a different process for java apps, I don't see how we can solve this problem.

Comment 7 Gene Snider 2010-09-02 22:52:28 UTC
Thanks for the explanation, Dan, it makes perfect sense.  I wondered why this AVC denial popped back up after all the other ones disappeared.


Comment 8 Kjartan Maraas 2010-09-09 15:57:45 UTC
According to the release notes for Oracle Java SE 6 JRE 1.6.0_10 it should be doing exactly that? Pasting from the release notes:


Java Plug-In technology (hereafter the "Java Plug-In"), which is included in the Java Runtime Environment, enables Java applets to run in popular web browsers on the desktop. The next-generation Java Plug-In, introduced in Java SE 6 Update 10, provides powerful new capabilities to applets in the web browser, while improving the overall reliability and functionality of applets in a backward-compatible manner.

The next-generation Java Plug-In offers a completely redesigned architecture. Instead of executing applets in the same operating system process as the web browser, the new plug-in runs one or more Java virtual machine instances ("JVMs") which connect back to the browser for full interoperability with the surrounding web page. This architectural change offers many advantages and enables several new features.

    * Improved reliability. The JVM running the applet is isolated from the web browser at the operating system level. If something should go wrong while running the applet, or if an uncooperative applet refuses to shut down, the new Java Plug-In detects and handles the error condition gracefully; the web browser is unaffected.

Comment 9 Art Sornat 2010-11-07 20:32:07 UTC
In my case it was a x86 system.

Comment 10 Daniel Walsh 2010-11-08 21:07:13 UTC
#setsebool -P allow_execstack 1

Will fix your problem.

Comment 11 Steffen Winther Sørensen 2010-11-08 21:44:38 UTC
True I was running the Oracle Java Plugin, latest version .22 I believe it was (not sitting at the F14 install right now thou)

Yeap allow_execstach should fix this, only some lusers won't know howto and might get confused about this AVC :)

Comment 12 Fedora Admin XMLRPC Client 2010-11-08 21:51:56 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 13 Fedora Admin XMLRPC Client 2010-11-08 21:54:50 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 14 Fedora Admin XMLRPC Client 2010-11-08 21:55:28 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 15 Rafał Polak 2010-11-08 22:19:38 UTC
It happens to me when I enable Moonlight 2.3 plugin in browser. I'm using 32bit system. It didn't happen in Fedora 13.

Comment 16 Art Sornat 2010-11-09 03:07:47 UTC
I'm not sure if it matters but I've upgraded from Fedora 13 it was not a fresh install. I've noticed some invalid links referencing a missing libgcj-4.4.4.jar file. I've installed the latest libgcj package version and deleted broken libgcj links. Since then, I've not had this AVC issue.

Comment 17 Daniel Walsh 2010-11-09 13:26:32 UTC

*** This bug has been marked as a duplicate of bug 572791 ***

Comment 18 michael 2010-11-17 21:03:28 UTC
Selinux problem with moonlight plugin in Firefox, Fedora 14 32 bit.

Comment 19 Daniel Walsh 2010-11-17 21:34:49 UTC
Turn on the allow_execstack boolean or change label of firefox to execmem_exec_t

Comment 20 Laszlo Kulcsar 2010-12-11 08:49:10 UTC
On Fedora 14 there is no lib32 directory. The right command concerning the solution:

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

Comment 21 sandblasted 2011-03-12 14:16:35 UTC
(In reply to comment #20)
> On Fedora 14 there is no lib32 directory. The right command concerning the
> solution:
> chcon -t execmem_exec_t '/usr/lib/firefox-3.6/firefox'

Laszlo, i tried your fix. let's see if solves it.


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