Summary: 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 denied.] 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 '/usr/lib64/nspluginwrapper/plugin-config'" 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 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 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) 2.6.31.5-117.fc12.x86_64 #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;
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.
*** This bug has been marked as a duplicate of bug 533987 ***
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
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
If you run firefox what context is it running with? ps -eZ | grep firefox
[root@epohost ~]# ps -eZ|grep firefox unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 2265 ? 00:00:01 firefox
And you are still seeing the execstack error?
Every time I launch firefox.
Erik can you install the selinux-policy package from updates-testing. selinux-policy-3.6.32-46.fc12.noarch And see if this is fixed there.
It'll have to wait. This package is not yet available from updates-testing. Do you see anything from the strace I attached?
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
Is that in the selinux-policy package?
Yes they are rules in selinux-policy-targeted
When will it be pushed to updates-testing?
It has been pushed, I guess it has not reached the mirrors yet.
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.
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.
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.
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
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.
Oh, and I do not have any package nvidia. I use mesa-dri-drivers-experimental.
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: http://labs.adobe.com/downloads/flashplayer10_64bit.html Plus: [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 jdk-1.6.0_17-fcs.x86_64 [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]$
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.
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.
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: /usr/lib64/mozilla/plugins I fixed it with: execstack -c /usr/java/jdk1.6.0_17/jre/lib/amd64/libnpjp2.so This file is from the package: jdk-1.6.0_17-fcs.x86_64 From the java.sun.com website.
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.
Do you have a java executable that is not labeled java_exec_t?
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.
If you label all of the executables in that directory java_exec_t does the problem go away?
chcon -t java_exec_t /usr/java/jre1.6.0_17/bin/*
selinux-policy-3.6.32-49.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-49.fc12
(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.
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
This update has solved it for me.
Eddie, could you click the link above and update the karma please.
i am giving the above command for the update...my results..."no packages selected for update" . Is there something i am doing wrong...?
Vasilis you might have it installed already. rpm -q selinux-policy-targeted
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.