Summary: SELinux is preventing /opt/Adobe/Reader9/Reader/intellinux/bin/acroread from making the program stack executable. Detailed Description: The acroread 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 acroread 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 acroread to run correctly, you can change the context of the executable to execmem_exec_t. "chcon -t execmem_exec_t '/opt/Adobe/Reader9/Reader/intellinux/bin/acroread'" 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 '/opt/Adobe/Reader9/Reader/intellinux/bin/acroread'" Fix Command: chcon -t execmem_exec_t '/opt/Adobe/Reader9/Reader/intellinux/bin/acroread' 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 acroread Source Path /opt/Adobe/Reader9/Reader/intellinux/bin/acroread Port <Unknown> Host (removed) Source RPM Packages AdobeReader_enu-9.3.2-1 Target RPM Packages Policy RPM selinux-policy-3.6.32-113.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name allow_execstack Host Name (removed) Platform Linux N03 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC 2010 x86_64 x86_64 Alert Count 5 First Seen Wed 21 Apr 2010 07:31:39 PM CDT Last Seen Sat 15 May 2010 09:14:22 AM CDT Local ID cfc20d76-96d0-47b6-ad9a-a8d7e8569d30 Line Numbers Raw Audit Messages node=N03 type=AVC msg=audit(1273932862.265:36): avc: denied { execstack } for pid=5399 comm="acroread" 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=N03 type=SYSCALL msg=audit(1273932862.265:36): arch=40000003 syscall=125 success=no exit=-13 a0=ffa82000 a1=1000 a2=1000007 a3=ffa82004 items=0 ppid=2945 pid=5399 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=2 comm="acroread" exe="/opt/Adobe/Reader9/Reader/intellinux/bin/acroread" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash String generated from allow_execstack,acroread,unconfined_t,unconfined_t,process,execstack audit2allow suggests: #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack' allow unconfined_t self:process execstack;
Did you try the suggested fix?
The the suggested fix: chcon -t execmem_exec_t '/opt/Adobe/Reader9/Reader/intellinux/bin/acroread' works like a charm. What I don't understand is why I get this bug on my 64-bit Dell laptop, but it never happens on my 64-bit Shuttle desktop. Both systems are running SELinux with the standard settings from the initial install.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Doug Morton, that fix works beautifully, thanks!
I disagree with closing this as NOTABUG. The suggested "fix" is a workaround, more than a fix. From a user experience point of view, I shouldn't have to make this fix manually. The SELinux policy should come with this already applied by default in its default policy. Otherwise, it just encourages people to turn off SELinux, to avoid the annoyance. I realize that you are probably going to say "it is Adobe's fault, not our fault". Personally, I consider that a cop-out. Personally, I don't really care about assigning blame; I care about the user experience. Right now, the user experience is poor. It would be easy for SELinux and Fedora to make the user experience better. SELinux should do so. Can we get this bug re-opened? Do you want me to open a new bug report?
So because adobe build a badly designed package that has been hacked every time, we should turn of SELinux protection to make sure this app runs? Security versus Usability is always going to be in contention, if you want a system that allows everything, that is what got Microsoft systems to be so hacked. If you run the evince package you will not have this problem. We are slowly being forced to loosen the protection because of such badly written code. But that does not make me feel positive.
"I realize that you are probably going to say "it is Adobe's fault, not our fault". Personally, I consider that a cop-out. Personally, I don't really care about assigning blame" " It would be easy for SELinux and Fedora to make the user experience better. SELinux should do so." Fedora do not support closed source software, you're lucky to have such a easy workaround at your disposition. If you do not agree with that then maybe you shouldn't be using Fedora in the first place. Adobe should fix their applications instead.
Its a 2 way street. Ideology doesn't hold up to reality in most situations...
Not sure what you mean by this. We are trying to accomidate adobe. We have the means to label it with a label that says it can do something we do not approve of. grep acroread /etc/selinux/targeted/contexts/files/file_contexts /usr/(local/)?acroread/(.*/)?intellinux/nppdf\.so -- system_u:object_r:textrel_shlib_t:s0 /usr/(local/)?acroread/(.*/)?lib/[^/]*\.so(\.[^/]*)* -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/acroread/.+\.api -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/acroread/(.*/)?nppdf\.so -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/acroread/(.*/)?sidecars/* -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/acroread/(.*/)?ADMPlugin\.apl -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/acroread/(.*/)?lib/[^/]*\.so(\.[^/]*)* -- system_u:object_r:textrel_shlib_t:s0 /opt/Adobe/Reader9/Reader/intellinux/bin/acroread -- system_u:object_r:execmem_exec_t:s0 If you installed it in the known locations using RPM it should have been labeled correctly. If you used something that adobe provides, then it would be their responsibility to make sure it installs successfully on Fedora by using restorecon or rpm. You have the ability to run restorecon on the app. If you install it in some different location, then you are responsible for setting the label. If you don't care about the check you can turn the check off, as described above. If the only way to make your user experience good is to default everyone to have this checked off so they can install any hacked up software that can use this attack, then you are lowering the security of everyone.
If you want to discuss this more, please bring it to the Fedora-Devel, Fedora-User or Fedora-SELinux list.