Bug 533486 - SELinux is preventing /usr/lib64/nspluginwrapper/plugin-config from making the program stack executable.
SELinux is preventing /usr/lib64/nspluginwrapper/plugin-config from making th...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-11-06 16:03 EST by Erik P. Olsen
Modified: 2011-06-17 07:39 EDT (History)
91 users (show)

See Also:
Fixed In Version: 3.6.32-49.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-01 11:40:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Strace of event. (39.30 KB, application/octet-stream)
2009-11-12 16:51 EST, Erik P. Olsen
no flags Details

  None (edit)
Description Erik P. Olsen 2009-11-06 16:03:46 EST

SELinux is preventing /usr/lib64/nspluginwrapper/plugin-config from making the
program stack executable.

Detailed Description:

[plugin-config has a permissive type (unconfined_t). This access was not

The plugin-config 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 (http://people.redhat.com/drepper/selinux-mem.html) web page explains how
to remove this requirement. If plugin-config 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
plugin-config to run correctly, you can change the context of the executable to
execmem_exec_t. "chcon -t execmem_exec_t
'/usr/lib64/nspluginwrapper/plugin-config'" 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/nspluginwrapper/plugin-config'

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                        plugin-config
Source Path                   /usr/lib64/nspluginwrapper/plugin-config
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           nspluginwrapper-1.3.0-8.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-41.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execstack
Host Name                     (removed)
Platform                      Linux (removed)
                              #1 SMP Wed Nov 4 11:15:52 EST 2009 x86_64 x86_64
Alert Count                   40
First Seen                    Thu 05 Nov 2009 14:47:18 CET
Last Seen                     Fri 06 Nov 2009 21:57:33 CET
Local ID                      31c465dc-ed6a-4bb9-b2e9-ab684835ed98
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1257541053.882:46): avc:  denied  { execstack } for  pid=3807 comm="plugin-config" 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(1257541053.882:46): arch=c000003e syscall=10 success=yes exit=128 a0=7fff8003d000 a1=1000 a2=1000007 a3=7f8bc9b4eaeb items=0 ppid=3805 pid=3807 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="plugin-config" exe="/usr/lib64/nspluginwrapper/plugin-config" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  selinux-policy-3.6.32-41.fc12,allow_execstack,plugin-config,unconfined_t,unconfined_t,process,execstack
audit2allow suggests:

#============= unconfined_t ==============
allow unconfined_t self:process execstack;
Comment 1 Erik P. Olsen 2009-11-12 16:51:35 EST
Created attachment 369336 [details]
Strace of event.

Since it happens every time I launch firefox I thought you might benefit from an strace which you can find attached.
Comment 2 Daniel Walsh 2009-11-12 17:26:43 EST

*** This bug has been marked as a duplicate of bug 533987 ***
Comment 3 Daniel Walsh 2009-11-16 11:18:05 EST
What is the settings of your booleans and what is the label on firefox?

# getsebool -a | grep nspl
allow_nsplugin_execmem --> on
allow_unconfined_nsplugin_transition --> off
nsplugin_can_network --> on

# ls -lZ /usr/lib64/firefox-3.5.5/firefox
-rwxr-xr-x. root root system_u:object_r:mozilla_exec_t:s0 /usr/lib64/firefox-3.5.5/firefox
Comment 4 Erik P. Olsen 2009-11-16 17:16:30 EST
Exactly the same as you show. From the horse's mouth:

[root@epohost ~]# getsebool -a|grep nspl
allow_nsplugin_execmem --> on
allow_unconfined_nsplugin_transition --> off
nsplugin_can_network --> on
[root@epohost ~]# ls -lZ /usr/lib64/firefox-3.5.5/firefox
-rwxr-xr-x. root root system_u:object_r:mozilla_exec_t:s0 /usr/lib64/firefox-3.5.5/firefox
Comment 5 Daniel Walsh 2009-11-16 17:31:33 EST
If you run firefox what context is it running with?

ps -eZ | grep firefox
Comment 6 Erik P. Olsen 2009-11-16 18:18:57 EST
[root@epohost ~]# ps -eZ|grep firefox
unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 2265 ? 00:00:01 firefox
Comment 7 Daniel Walsh 2009-11-17 08:06:38 EST
And you are still seeing the execstack error?
Comment 8 Erik P. Olsen 2009-11-17 08:37:34 EST
Every time I launch firefox.
Comment 9 Daniel Walsh 2009-11-17 08:48:24 EST
Erik can you install the selinux-policy package from updates-testing.


And see if this is fixed there.
Comment 10 Erik P. Olsen 2009-11-17 09:39:42 EST
It'll have to wait. This package is not yet available from updates-testing. Do you see anything from the strace I attached?
Comment 11 Daniel Walsh 2009-11-17 10:45:13 EST
No I think the problem was I was transitioning from unconfined_execmem_t to unconfiend_t when it executed a binary.
I removed this transition and it should stay unconfined_execmem_t
Comment 12 Erik P. Olsen 2009-11-17 11:20:20 EST
Is that in the selinux-policy package?
Comment 13 Daniel Walsh 2009-11-17 11:23:02 EST
Yes they are rules in selinux-policy-targeted
Comment 14 Erik P. Olsen 2009-11-18 05:17:25 EST
When will it be pushed to updates-testing?
Comment 15 Daniel Walsh 2009-11-18 07:53:27 EST
It has been pushed, I guess it has not reached the mirrors yet.
Comment 16 Erik P. Olsen 2009-11-19 06:32:25 EST
I finally got it. However, the problem is still present. It is unconfined_t and not as expected unconfined_execmem_t.

But I don't know how serious it is, I haven't found any side effect from it. Besides from this error message the system behaves normally. It has turned out that my java plugin problem with firefox had nothing to do with selinux - it was because the plugin was installed disabled by default, a fact I only discovered yesterday.
Comment 17 Daniel Walsh 2009-11-19 10:09:58 EST
I think you have an badly marked library

# find /usr/lib64 -name \*.so\* -exec execstack -q {} \;  2>/dev/null | grep ^X 
X /usr/lib64/libxvidcore.so.4.2

# find /lib64 -name \*.so\* -exec execstack -q {} \;  2>/dev/null | grep ^X 

Then clear the flag 

execstack -c /usr/lib64/libxvidcore.so.4.2

And see if everything still works.
Comment 18 winglessbuzzard 2009-11-19 10:21:08 EST
I am very new to Linux (first install of a Linux OS two days ago).  I'm guessing, I just open the terminal window and:

1. Paste
# find /usr/lib64 -name \*.so\* -exec execstack -q {} \;  2>/dev/null | grep ^X 
X /usr/lib64/libxvidcore.so.4.2
-hit enter if necessary
2. Paste
# find /lib64 -name \*.so\* -exec execstack -q {} \;  2>/dev/null | grep ^X 
-hit enter if necessary
3. Paste
execstack -c /usr/lib64/libxvidcore.so.4.2

Correct?  I am at work now, but I will try this when I get home.  If this is not what I need to do, please let me know exactly what I need to do... keeping in mind that I know almost nothing about what we're talking about, including what a 'library' is or how one could be 'badly marked'.  Sorry for my n00bgnorance.
Comment 19 Daniel Walsh 2009-11-19 10:33:18 EST
Yes, libxvidcore is an example of what the search might find.

Basically the find command is searching /usr/lib64 and /lib64 for badly marked libraries and then listing them out.

execstack -c

Clears the flags of any libraries saying they need execstack.  Some developers build libraries in such a way that they incorrectly request this access.

You can also tell your system that you do not care about this access by executing

setsebool -P allow_execstack 0

Most likely you installed somepackage from rpmfusion or nvidia which is causing the problem
Comment 20 Erik P. Olsen 2009-11-19 11:03:07 EST
There was no output from the two finds, hence no flag to clear.

The fedora 12 system I am running is a test system build on an early rawhide which has been constantly updated so I assume that it now is or rather should be equal to vanilla fedora 12. Could it be that some badly marked library comes from this rawhide and has never been cleared?

Anyway I intent to build a new fedora 12 system as my production system and it shall be interesting to see if it gets hit by the same problem. This means that the test system will be discontinued. I'll report back what my findings are with the new system.
Comment 21 Erik P. Olsen 2009-11-19 11:13:49 EST
Oh, and I do not have any package nvidia. I use mesa-dri-drivers-experimental.
Comment 22 Ken Barber 2009-11-19 12:45:52 EST
I get this when browsing to YouTube in Firefox more often then not. I'm using the Adobe Flash Plugin 64 bit that is from here:



[ken@oscar ~]$ ls -la /usr/lib64/mozilla/plugins
total 388
drwxr-xr-x. 2 root root   4096 2009-11-17 17:44 .
drwxr-xr-x. 5 root root   4096 2009-11-17 16:16 ..
lrwxrwxrwx. 1 root root     43 2009-11-17 17:43 libnpjp2.so -> /usr/java/default/jre/lib/amd64/libnpjp2.so
-rwxr-xr-x. 1 root root   5264 2009-11-03 11:58 librhythmbox-itms-detection-plugin.so
-rwxr-xr-x. 1 root root 103496 2009-11-03 13:30 libtotem-cone-plugin.so
-rwxr-xr-x. 1 root root 110664 2009-11-03 13:30 libtotem-gmp-plugin.so
-rwxr-xr-x. 1 root root  74968 2009-11-03 13:30 libtotem-mully-plugin.so
-rwxr-xr-x. 1 root root  80960 2009-11-03 13:30 libtotem-narrowspace-plugin.so
[ken@oscar ~]$ 

The libnjp2.so is from Sun JDK:

[ken@oscar ~]$ rpm -qf /usr/java/default/jre/lib/amd64/libnpjp2.so 
[ken@oscar ~]$ 

Checking the exec status:

[ken@oscar plugins]$ execstack -q *
? libnpjp2.so
- librhythmbox-itms-detection-plugin.so
- libtotem-cone-plugin.so
- libtotem-gmp-plugin.so
- libtotem-mully-plugin.so
- libtotem-narrowspace-plugin.so
[ken@oscar plugins]$
Comment 23 Erik P. Olsen 2009-11-19 13:54:54 EST
I don't know if I have solved the problem but at least I have removed the irritating error messages by:

chcon -t execmem_exec_t '/usr/lib64/nspluginwrapper/plugin-config'
and to make it sticky:
semanage fcontext -a -t execmem_exec_t '/usr/lib64/nspluginwrapper/plugin-config'

It is all mentioned in the abrt message (see bug description above), I just didn't dare to try it at the beginning.
Comment 24 Daniel Walsh 2009-11-19 14:19:09 EST
Well that will fix it.  I also was going to suggest you search for these libraries in your home dir.

I usually close these bugs as a dup of the allow_execstack bugzilla.
Comment 25 Ken Barber 2009-11-19 16:35:14 EST
I can confirm the other 'chcon' fix described does stop the errors. I found an alternate fix. I've avoided selinux up until now. Excuse my ignorance.

Zooming further for me it was the Java firefox plugin that I had linked into:


I fixed it with:

execstack -c /usr/java/jdk1.6.0_17/jre/lib/amd64/libnpjp2.so

This file is from the package:


From the java.sun.com website.
Comment 26 Erik P. Olsen 2009-11-20 14:48:05 EST
Re comment #20: I have now installed GA fedora 12 and the problem is still there. The commands mentioned in comment #23 stop the errors from popping up.

Re comment #24: I've searched the entire system and found no occurrence of badly flagged libs.

Maybe the problem is something else. I noticed no errors when launching firefox prior to installing Sun's java plugin. After installing the plugin the error popped up and so it also did after removal of the plugin.
Comment 27 Daniel Walsh 2009-11-20 16:35:17 EST
Do you have a java executable that is not labeled java_exec_t?
Comment 28 Erik P. Olsen 2009-11-20 17:06:02 EST
java, java_wm and javaws are labeled java_exec_t:s0 the rest of that library (/usr/java/jre1.6.0_17/bin) are labeled system_u:object_r:bin_t:s0.
Comment 29 Daniel Walsh 2009-11-23 08:14:37 EST
If you label all of the executables in that directory java_exec_t does the problem go away?
Comment 30 Daniel Walsh 2009-11-23 08:15:13 EST
chcon -t java_exec_t /usr/java/jre1.6.0_17/bin/*
Comment 31 Fedora Update System 2009-11-23 18:41:08 EST
selinux-policy-3.6.32-49.fc12 has been submitted as an update for Fedora 12.
Comment 32 Erik P. Olsen 2009-11-23 18:48:14 EST
(In reply to comment #30)
> chcon -t java_exec_t /usr/java/jre1.6.0_17/bin/*  

Sorry but I can't reproduce the error anylonger. Since I made the change described in comment #23 I haven't had the problem. I even reinstalled jre1.6.0_17 but the error messages are gone. I guess that's because the change remained in effect.

Someone else will have to make the test.
Comment 33 Fedora Update System 2009-11-25 10:24:27 EST
selinux-policy-3.6.32-49.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12131
Comment 34 Eddie Lania 2009-11-26 11:56:39 EST
This update has solved it for me.
Comment 35 Miroslav Grepl 2009-11-27 07:12:13 EST

could you click the link above and update the karma please.
Comment 36 Vasilis Stergiou 2009-11-30 17:39:04 EST
i am giving the above command for the update...my results..."no packages selected for update" . Is there something i am doing wrong...?
Comment 37 Daniel Walsh 2009-12-01 09:56:00 EST
Vasilis you might have it installed already.

rpm -q selinux-policy-targeted
Comment 38 Fedora Update System 2009-12-01 23:35:32 EST
selinux-policy-3.6.32-49.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

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