Bug 654173

Summary: SELinux is preventing /usr/bin/rekonq from making the program stack executable.
Product: [Fedora] Fedora Reporter: Neil Underwood <n.underwood78>
Component: rekonqAssignee: Eelko Berkenpies <fedora>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: dwalsh, fedora, kevin, mgrepl, rdieter, thomasj
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:8a9394dc9814df58f66e505c569e1d59bdb4ab4c26db2ef70e01f88d0e26cea7
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-29 14:18:34 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 Neil Underwood 2010-11-17 02:57:16 UTC
Summary:

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

Detailed Description:

The rekonq 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://www.akkadia.org/drepper/selinux-mem.html) web page explains how to
remove this requirement. If rekonq 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 rekonq to
run correctly, you can change the context of the executable to execmem_exec_t.
"chcon -t execmem_exec_t '/usr/bin/rekonq'" 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/rekonq'"

Fix Command:

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

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                        rekonq
Source Path                   /usr/bin/rekonq
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           rekonq-0.6.1-1.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-10.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   allow_execstack
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.6-48.fc14.x86_64 #1 SMP
                              Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 16 Nov 2010 06:53:02 PM PST
Last Seen                     Tue 16 Nov 2010 06:53:02 PM PST
Local ID                      fe043075-37ef-486d-80ad-f214ae05fd98
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1289962382.743:28185): avc:  denied  { execstack } for  pid=2564 comm="rekonq" 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(1289962382.743:28185): arch=c000003e syscall=10 success=no exit=-13 a0=7fff189c7000 a1=1000 a2=1000007 a3=35f5820000 items=0 ppid=1 pid=2564 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="rekonq" exe="/usr/bin/rekonq" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  allow_execstack,rekonq,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-11-17 16:02:34 UTC
Why does this need execstack?  Is it written in java?

Comment 2 Rex Dieter 2011-04-29 12:19:33 UTC
I suspect this may be a dup (or variant) of bug #604003

Comment 3 Rex Dieter 2011-04-29 12:27:49 UTC
Fwiw, I cannot reproduce on my f14/x86_64 box.

(and to answer comment #1 , not written in java, but qt/c++ and uses qtwebkit)

Comment 4 Daniel Walsh 2011-04-29 14:18:34 UTC

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

Comment 5 Kevin Kofler 2011-04-29 14:23:50 UTC
Uh, bug 604003 is about execmem, this one is asking for execstack.

I suspect this being the result of some browser plugin.

Comment 6 Daniel Walsh 2011-04-29 15:05:17 UTC
Actually they are usually caused by NVIDIA Drivers or some library incorrectly marked as requiring execstack.

Closing as a dup of allow_execstack bug, which tells you how to look for these libraries.

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