Summary: SELinux is preventing /usr/lib/thunderbird-3.0b4/thunderbird-bin from making the program stack executable. Detailed Description: The thunderbird-bin 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 thunderbird-bin 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 thunderbird-bin to run correctly, you can change the context of the executable to execmem_exec_t. "chcon -t execmem_exec_t '/usr/lib/thunderbird-3.0b4/thunderbird-bin'" 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/thunderbird-3.0b4/thunderbird-bin'" Fix Command: chcon -t execmem_exec_t '/usr/lib/thunderbird-3.0b4/thunderbird-bin' 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 thunderbird-bin Source Path /usr/lib/thunderbird-3.0b4/thunderbird-bin Port <Unknown> Host (removed) Source RPM Packages thunderbird-3.0-3.9.b4.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-127.fc12.i686 #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i686 Alert Count 20 First Seen Mon 09 Nov 2009 05:56:36 PM EST Last Seen Mon 09 Nov 2009 06:37:50 PM EST Local ID beb39629-4b26-44bf-9acb-aadde9042ffb Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1257809870.922:74): avc: denied { execstack } for pid=10204 comm="thunderbird-bin" 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(1257809870.922:74): arch=40000003 syscall=125 success=no exit=-13 a0=bfe79000 a1=1000 a2=1000007 a3=bfe78120 items=0 ppid=10200 pid=10204 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="thunderbird-bin" exe="/usr/lib/thunderbird-3.0b4/thunderbird-bin" 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,thunderbird-bin,unconfined_t,unconfined_t,process,execstack audit2allow suggests: #============= unconfined_t ============== allow unconfined_t self:process execstack;
Do you have some closed source drivers or shared libraries installed? nvidia drivers? rpmfusion codecs? These are built incorrectly and require a dangerous priv execstack. This link http://people.redhat.com/~drepper/selinux-mem.html explains the access. You can use the command execstack -q to try to find the libraries with the execstack flag on, I use a command like find /usr/lib64 -name \*.so\* -exec execstack -q {} \; -print | grep ^X Then try to turn off the flag of any libraries that require execstack execstack -c And see if the apps work. If you can not find the problem library or the libraray does not work without the execstack flag turned on, your only option is to tell SELinux to stop checking for execstack by setting the boolean allow_execstack. setsebool -P allow_execstack 1
*** Bug 533454 has been marked as a duplicate of this bug. ***
*** Bug 533715 has been marked as a duplicate of this bug. ***
*** Bug 536688 has been marked as a duplicate of this bug. ***
*** Bug 533486 has been marked as a duplicate of this bug. ***
OK. I've isolated the problem on my setup to be Sun's java: jre-1.6.0_17-fsc
*** Bug 537636 has been marked as a duplicate of this bug. ***
*** Bug 537790 has been marked as a duplicate of this bug. ***
Eric, can you describe what you figured out? Is thunderbird running java directly?
Actually, it's not thunderbird, it's firefox. I refer to bug 533486 which has been declared duplicate of this bug. When I remove Sun's java from the plugins directory I don't get hit by the bug. And when I disable SELinux I can run normally with firefox and the java plugin from Sun.
*** Bug 537699 has been marked as a duplicate of this bug. ***
rpmfusion has a bug (90) for this problem as it affects the proprietary nvidia drivers. i've asked about a) talking to nvidia about it and b) creating a policy for it. does anyone know if a similar request has been raised with sun regarding their java package? also, when i ran that execstack command line i got lots of errors i had trouble filtering out, which made it tricky to see what was going on. this probably isn't the best solution but i ended up with this: find /usr/lib* -name \*.so\* | while read line; do execstack -q $line 2>/dev/null | grep ^X; done which showed up /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so - from java-1.6.0-openjdk-1.6.0.0-33.b16.fc12.x86_64 as also needing execstack. not sure if we should be worried about that.
If you clear the flag using execstack -c, does it work?
*** Bug 538141 has been marked as a duplicate of this bug. ***
*** Bug 538413 has been marked as a duplicate of this bug. ***
*** Bug 538764 has been marked as a duplicate of this bug. ***
*** Bug 539333 has been marked as a duplicate of this bug. ***
*** Bug 539398 has been marked as a duplicate of this bug. ***
*** Bug 539359 has been marked as a duplicate of this bug. ***
*** Bug 539409 has been marked as a duplicate of this bug. ***
*** Bug 539425 has been marked as a duplicate of this bug. ***
*** Bug 539531 has been marked as a duplicate of this bug. ***
*** Bug 539713 has been marked as a duplicate of this bug. ***
*** Bug 539867 has been marked as a duplicate of this bug. ***
> which showed up > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so - > from java-1.6.0-openjdk-1.6.0.0-33.b16.fc12.x86_64 as also needing execstack. > not sure if we should be worried about that. Sounds like it. I can confirm that I get the same. On my system, with no nvidia, this is the only execstack file. (On a similar system, but with nvidia drivers, only this file and the nvidia libs need execstack.) Not sure this is CANTFIX--should this be either reopened, or reclassified as an openjdk bug? What on earth is that file (and the rest of them) doing in /usr/lib rather than /usr/lib64, by the way? James
*** Bug 539799 has been marked as a duplicate of this bug. ***
*** Bug 539974 has been marked as a duplicate of this bug. ***
*** Bug 540332 has been marked as a duplicate of this bug. ***
*** Bug 540195 has been marked as a duplicate of this bug. ***
*** Bug 539969 has been marked as a duplicate of this bug. ***
*** Bug 539813 has been marked as a duplicate of this bug. ***
*** Bug 540021 has been marked as a duplicate of this bug. ***
*** Bug 540073 has been marked as a duplicate of this bug. ***
*** Bug 540993 has been marked as a duplicate of this bug. ***
*** Bug 541036 has been marked as a duplicate of this bug. ***
*** Bug 541178 has been marked as a duplicate of this bug. ***
*** Bug 541329 has been marked as a duplicate of this bug. ***
*** Bug 541384 has been marked as a duplicate of this bug. ***
*** Bug 541489 has been marked as a duplicate of this bug. ***
*** Bug 541493 has been marked as a duplicate of this bug. ***
*** Bug 541484 has been marked as a duplicate of this bug. ***
*** Bug 541647 has been marked as a duplicate of this bug. ***
*** Bug 541665 has been marked as a duplicate of this bug. ***
*** Bug 541746 has been marked as a duplicate of this bug. ***
*** Bug 541681 has been marked as a duplicate of this bug. ***
*** Bug 542421 has been marked as a duplicate of this bug. ***
*** Bug 542515 has been marked as a duplicate of this bug. ***
*** Bug 542336 has been marked as a duplicate of this bug. ***
*** Bug 542483 has been marked as a duplicate of this bug. ***
*** Bug 541629 has been marked as a duplicate of this bug. ***
We've now had this bug reported 44 times! Does that make a case for a tweak to abrt to give it better duplicate detection logic? I've noticed it often finds for itself that a bug report is a duplicate, but there's clearly room for improvement. Might be worth it even on an ad hoc basis, e.g., add a rule that anything with the title '(allow_execstack) SELinux is preventing /usr/lib/thunderbird-3.0b4/thunderbird-bin from making the program stack executable' is a duplicate of this. DW and MG must be losing the will to live just flagging duplicates.
*** Bug 541674 has been marked as a duplicate of this bug. ***
*** Bug 541837 has been marked as a duplicate of this bug. ***
*** Bug 542772 has been marked as a duplicate of this bug. ***
*** Bug 542719 has been marked as a duplicate of this bug. ***
*** Bug 542252 has been marked as a duplicate of this bug. ***
*** Bug 542360 has been marked as a duplicate of this bug. ***
*** Bug 542499 has been marked as a duplicate of this bug. ***
*** Bug 541922 has been marked as a duplicate of this bug. ***
*** Bug 542960 has been marked as a duplicate of this bug. ***
*** Bug 538659 has been marked as a duplicate of this bug. ***
*** Bug 543086 has been marked as a duplicate of this bug. ***
*** Bug 543145 has been marked as a duplicate of this bug. ***
*** Bug 543493 has been marked as a duplicate of this bug. ***
*** Bug 543804 has been marked as a duplicate of this bug. ***
*** Bug 543891 has been marked as a duplicate of this bug. ***
*** Bug 543939 has been marked as a duplicate of this bug. ***
I am confused.. running the command for execstack -q in the following form find /usr/lib64 -name \*.so\* -exec execstack -q {} \; -print | grep ^X as stated above tells me that no such file exists. then I navigate to the folder and there exactly is no folder by that name i.e. 'lib64' now what is this.. I have allowed execstack by setting the boolean value.. but I am afraid the same bug will come up again.
You also should look in /lib64 Suraj are you using xguest?
*** Bug 544453 has been marked as a duplicate of this bug. ***
*** Bug 544694 has been marked as a duplicate of this bug. ***
*** Bug 545617 has been marked as a duplicate of this bug. ***
*** Bug 545844 has been marked as a duplicate of this bug. ***
*** Bug 545894 has been marked as a duplicate of this bug. ***
*** Bug 546162 has been marked as a duplicate of this bug. ***
*** Bug 546349 has been marked as a duplicate of this bug. ***
*** Bug 546383 has been marked as a duplicate of this bug. ***
*** Bug 546689 has been marked as a duplicate of this bug. ***
*** Bug 546776 has been marked as a duplicate of this bug. ***
*** Bug 547325 has been marked as a duplicate of this bug. ***
*** Bug 548159 has been marked as a duplicate of this bug. ***
*** Bug 548506 has been marked as a duplicate of this bug. ***
*** Bug 549440 has been marked as a duplicate of this bug. ***
*** Bug 533535 has been marked as a duplicate of this bug. ***
*** Bug 532239 has been marked as a duplicate of this bug. ***
*** Bug 530816 has been marked as a duplicate of this bug. ***
*** Bug 536964 has been marked as a duplicate of this bug. ***
*** Bug 537675 has been marked as a duplicate of this bug. ***
*** Bug 538545 has been marked as a duplicate of this bug. ***
*** Bug 539226 has been marked as a duplicate of this bug. ***
*** Bug 543051 has been marked as a duplicate of this bug. ***
*** Bug 550380 has been marked as a duplicate of this bug. ***
*** Bug 550509 has been marked as a duplicate of this bug. ***
*** Bug 550718 has been marked as a duplicate of this bug. ***
*** Bug 551361 has been marked as a duplicate of this bug. ***
*** Bug 553504 has been marked as a duplicate of this bug. ***
*** Bug 553468 has been marked as a duplicate of this bug. ***
*** Bug 558118 has been marked as a duplicate of this bug. ***
*** Bug 558153 has been marked as a duplicate of this bug. ***
*** Bug 560677 has been marked as a duplicate of this bug. ***
*** Bug 583294 has been marked as a duplicate of this bug. ***
*** Bug 583369 has been marked as a duplicate of this bug. ***
*** Bug 584404 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > This link > > http://people.redhat.com/~drepper/selinux-mem.html > > explains the access. > Dan, The link seems to be dead. Do you have any other reading suggestions for people interested in learning about execstack issues?
http://www.akkadia.org/drepper/selinux-mem.html
*** Bug 652297 has been marked as a duplicate of this bug. ***
AdbeRdr9.4-1_i486linux_enu.rpm installed files that triggered this denial also: /opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied The work-around above fixed the issue for me. # pwd /opt/Adobe/Reader9/Reader/intellinux/lib # find . -name \*.so\* -exec execstack -q {} \; -print | grep ^X X ./libcrypto.so.0 X ./libcrypto.so X ./libcrypto.so.0.9.8 X ./libsccore.so # execstack -c libcrypto.so* libsccore.so # find . -name \*.so\* -exec execstack -q {} \; -print | grep ^X # acroread would start up after making this change.