Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 592584 - SELinux is preventing /opt/Adobe/Reader9/Reader/intellinux/bin/acroread from making the program stack executable.
SELinux is preventing /opt/Adobe/Reader9/Reader/intellinux/bin/acroread from ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:30b13413702...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-15 10:54 EDT by Doug Morton
Modified: 2010-12-03 09:08 EST (History)
49 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-29 13:57:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Morton 2010-05-15 10:54:45 EDT
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;
Comment 1 Daniel Walsh 2010-05-17 09:26:08 EDT
Did you try the suggested fix?
Comment 2 Doug Morton 2010-05-17 15:23:06 EDT
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.
Comment 3 Carl G. 2010-06-29 13:57:19 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Jeremey Hustman 2010-11-05 16:08:01 EDT
Doug Morton, that fix works beautifully, thanks!
Comment 5 D. Wagner 2010-11-21 22:08:25 EST
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?
Comment 6 Daniel Walsh 2010-11-22 12:18:27 EST
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.
Comment 7 Carl G. 2010-11-22 18:45:12 EST
"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.
Comment 8 Steven Haigh 2010-11-23 03:18:09 EST
Its a 2 way street. Ideology doesn't hold up to reality in most situations...
Comment 9 Daniel Walsh 2010-11-23 09:46:02 EST
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.
Comment 10 Daniel Walsh 2010-11-23 09:46:39 EST
If you want to discuss this more, please bring it to the Fedora-Devel, Fedora-User or Fedora-SELinux list.

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