Bug 530816

Summary: SELinux is preventing /usr/bin/nautilus from making the program stack executable.
Product: [Fedora] Fedora Reporter: Scott Worley <dswbike>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: drepper, dwalsh, mgrepl, peter.soderlind
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:cf9fb9bf708a5abb214b82a8a36197beb90449cf1df6f1b67781cda829552a02
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-23 16:33:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Scott Worley 2009-10-25 12:03:43 UTC
Summary:

SELinux is preventing /usr/bin/nautilus from making the program stack
executable.

Detailed Description:

[nautilus has a permissive type (unconfined_t). This access was not denied.]

The nautilus 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 nautilus 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 nautilus to
run correctly, you can change the context of the executable to execmem_exec_t.
"chcon -t execmem_exec_t '/usr/bin/nautilus'" 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/bin/nautilus'"

Fix Command:

chcon -t execmem_exec_t '/usr/bin/nautilus'

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                        nautilus
Source Path                   /usr/bin/nautilus
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           nautilus-2.28.1-1.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-27.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-96.fc12.x86_64 #1 SMP Fri Oct 23 19:30:30
                              EDT 2009 x86_64 x86_64
Alert Count                   5
First Seen                    Fri 23 Oct 2009 06:26:52 PM EDT
Last Seen                     Sun 25 Oct 2009 08:01:42 AM EDT
Local ID                      44b71217-3247-4758-8a0f-63b2f2ab5800
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1256472102.139:26907): avc:  denied  { execstack } for  pid=1983 comm="nautilus" 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(1256472102.139:26907): arch=c000003e syscall=10 success=yes exit=73014444160 a0=7ffff9997000 a1=1000 a2=1000007 a3=3ae621aa79 items=0 ppid=1791 pid=1983 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=2 comm="nautilus" exe="/usr/bin/nautilus" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  selinux-policy-3.6.32-27.fc12,allow_execstack,nautilus,unconfined_t,unconfined_t,process,execstack
audit2allow suggests:

#============= unconfined_t ==============
allow unconfined_t self:process execstack;

Comment 1 Daniel Walsh 2009-10-26 13:20:16 UTC
Are you using any closed source drivers like nvidia?

You can turn on the allow_execstack boolean if you want to ignore this check.

setsebool -P allow_execstack 1

Comment 2 Scott Worley 2009-10-28 00:07:32 UTC
Thanks,

Yes, I'm using fluendo-codecs-complete-6-1.i386.rpm and libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz

I guess I will ignore the SELinux notification. I don't want to turn on allow_execstack.

Does anyone know of a detailed technical description of why these accursed codecs use executable stacks?

Comment 3 Ulrich Drepper 2009-10-28 14:00:38 UTC
(In reply to comment #2)
> Does anyone know of a detailed technical description of why these accursed
> codecs use executable stacks?  

There likely is no reason.  They likely contain code from asm files and the developers don't add the appropriate magic to the assember or source to day there are no execstack requirements.

Find the offending DSO (with execstack) and then just clear the bit (also with execstack).

Comment 4 Bug Zapper 2009-11-16 14:15:25 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Daniel Walsh 2009-12-23 16:33:49 UTC

*** This bug has been marked as a duplicate of bug 533987 ***