Bug 652297 (allow_execstack) - SELinux is preventing /usr/bin/gcm-session from making the program stack executable.
Summary: SELinux is preventing /usr/bin/gcm-session from making the program stack exec...
Keywords:
Status: CLOSED DUPLICATE of bug 678818
Alias: allow_execstack
Product: Fedora
Classification: Fedora
Component: SDL
Version: 14
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:fe151899c2d...
: 246171 642673 654068 654173 655131 655353 655362 657708 657786 657949 658708 660068 660146 661807 662609 663505 663884 665039 665458 665932 665948 666069 666156 666200 666202 666208 666218 666303 666325 666333 666411 666415 666458 666485 666562 666571 666638 666639 666652 666831 667093 667212 667904 667956 668136 668236 668305 668416 669068 669800 669879 670019 670027 671000 671197 671390 671898 671918 673642 674739 678123 679093 679199 680540 682824 689362 694342 696544 697170 701147 784144 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-11 15:28 UTC by Andrea Dell'Amico
Modified: 2013-07-15 20:26 UTC (History)
82 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-23 17:34:39 UTC
Type: ---


Attachments (Terms of Use)
This python program can be used to search for the execstack libraries (952 bytes, application/octet-stream)
2011-01-17 18:38 UTC, Daniel Walsh
no flags Details
Here is the proposed alerts output. (1.34 KB, text/plain)
2011-01-18 19:10 UTC, Daniel Walsh
no flags Details

Description Andrea Dell'Amico 2010-11-11 15:28:10 UTC
Summary:

SELinux is preventing /usr/bin/gcm-session from making the program stack
executable.

Detailed Description:

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

Fix Command:

chcon -t execmem_exec_t '/usr/bin/gcm-session'

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                        flegita
Source Path                   /usr/bin/flegita
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           gnome-color-manager-2.32.0-2.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-7.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.i686.PAE #1 SMP Fri
                              Oct 22 15:27:53 UTC 2010 i686 i686
Alert Count                   3
First Seen                    Tue 09 Nov 2010 01:52:14 AM CET
Last Seen                     Tue 09 Nov 2010 06:39:05 PM CET
Local ID                      3306aac4-5876-4e5b-9300-216711ede467
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1289324345.409:26974): avc:  denied  { execstack } for  pid=10959 comm="gcm-session" 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(1289324345.409:26974): arch=40000003 syscall=125 success=no exit=-13 a0=bfa2e000 a1=1000 a2=1000007 a3=b5c45c60 items=0 ppid=1 pid=10959 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gcm-session" exe="/usr/bin/gcm-session" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  allow_execstack,flegita,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-11 21:35:59 UTC

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

Comment 2 Daniel Walsh 2010-11-11 21:37:54 UTC
You have to either set the label to execmem_exec_t or turn the check off

#setsebool -P allow_execstack 1

Comment 3 Daniel Walsh 2010-11-12 14:49:06 UTC
I think we had this bug before on gcm-coller-manager?

Comment 4 Richard Hughes 2010-11-12 21:12:21 UTC
What would be the root cause of it needing execstack? Something like overrunning a buffer that would be picked up on valgrind? Thanks.

Comment 5 Daniel Walsh 2010-11-15 14:58:49 UTC
You could look for libraries that are marked as requiring execstack

# find /lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
# find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 

or

# find /lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
# find /usr/lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X

Comment 6 Richard Hughes 2010-11-15 16:25:57 UTC
(In reply to comment #5)
> You could look for libraries that are marked as requiring execstack
> 
> # find /lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
> # find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 

I get no entries on my system. Andrea, what does this report for you?

Comment 7 Daniel Walsh 2010-11-15 16:32:00 UTC
I think this might be specific to Andrea's machine.  Andrea are you running nvidia drivers?

Comment 8 Andrea Dell'Amico 2010-11-15 16:53:38 UTC
No NVIDIA drivers. It's a Lenovo laptop 3000V100, the graphics card is an Intel 950GM.

The libraries that require execstack:


/usr/lib/cups/filter/rastertosamsungsplc
/usr/lib/libmono.so
/usr/lib/libmono.so.0.0.0
/usr/lib/libmono.so.0
/usr/lib/sane/libsane-smfp.so.1
/usr/lib/sane/libsane-smfp.so
/usr/lib/sane/libsane-smfp.so.1.0.1

Leaving the mono ones, the other come with a proprietary samsung printer driver. I didn't associate the error with those files, but maybe I'm wrong?

Comment 9 Daniel Walsh 2010-11-15 17:05:27 UTC
Can you execute 

execstack -c 

on those files and see if your printing still works.  gcm does some stuff with printing that probably sucks in these libraries.

Comment 10 Andrea Dell'Amico 2010-11-15 17:51:36 UTC
Printing still works, and no more SELinux alerts from gcm-session.

Thanks to all,
Andrea

Comment 11 Daniel Walsh 2010-11-16 16:52:09 UTC
Ok could you report this as a bug to samsung, (to get a clue).  I mean to fix the way they ship their libraries to not mark the libraries as requiring execstack.

Comment 12 Andrea Dell'Amico 2010-11-17 18:58:26 UTC
I'll do, thanks. The driver is a tar file that contains the libraries and some scripts, SELinux is completely ignored.

Comment 13 Daniel Walsh 2010-11-17 19:15:57 UTC
Yes, SELinux should be ignored.  It should not be needed, but their libraries are either built incorrectly or some how end up with a flag on them telling the system they need execstack.

Comment 14 Andrea Dell'Amico 2010-11-17 19:23:05 UTC
I needed to relabel some files under /usr/share/cups, after the installation of the driver. execstac wasn't the only problem with that driver.

Sorry, I mixed two issues.

Comment 15 Daniel Walsh 2010-11-17 21:35:32 UTC
*** Bug 654068 has been marked as a duplicate of this bug. ***

Comment 16 Daniel Walsh 2010-11-19 18:28:13 UTC
*** Bug 655131 has been marked as a duplicate of this bug. ***

Comment 17 Miroslav Grepl 2010-11-22 08:42:21 UTC
*** Bug 655362 has been marked as a duplicate of this bug. ***

Comment 18 Miroslav Grepl 2010-11-22 09:55:53 UTC
*** Bug 655353 has been marked as a duplicate of this bug. ***

Comment 19 Miroslav Grepl 2010-11-28 23:29:38 UTC
*** Bug 657786 has been marked as a duplicate of this bug. ***

Comment 20 Miroslav Grepl 2010-11-28 23:30:12 UTC
*** Bug 657708 has been marked as a duplicate of this bug. ***

Comment 21 Miroslav Grepl 2010-11-28 23:30:37 UTC
*** Bug 657949 has been marked as a duplicate of this bug. ***

Comment 22 Miroslav Grepl 2010-12-01 09:21:39 UTC
*** Bug 658708 has been marked as a duplicate of this bug. ***

Comment 23 Miroslav Grepl 2010-12-06 13:24:18 UTC
*** Bug 660068 has been marked as a duplicate of this bug. ***

Comment 24 Miroslav Grepl 2010-12-06 13:39:57 UTC
*** Bug 660146 has been marked as a duplicate of this bug. ***

Comment 25 Daniel Walsh 2010-12-10 19:53:13 UTC
*** Bug 661807 has been marked as a duplicate of this bug. ***

Comment 26 Miroslav Grepl 2010-12-13 12:31:28 UTC
*** Bug 662609 has been marked as a duplicate of this bug. ***

Comment 27 Miroslav Grepl 2010-12-16 09:37:09 UTC
*** Bug 663505 has been marked as a duplicate of this bug. ***

Comment 28 Daniel Walsh 2010-12-28 13:20:34 UTC
*** Bug 665948 has been marked as a duplicate of this bug. ***

Comment 29 Daniel Walsh 2010-12-28 20:09:22 UTC
*** Bug 642673 has been marked as a duplicate of this bug. ***

Comment 30 Daniel Walsh 2010-12-28 20:14:31 UTC
*** Bug 666069 has been marked as a duplicate of this bug. ***

Comment 31 Daniel Walsh 2010-12-28 20:23:33 UTC
*** Bug 665458 has been marked as a duplicate of this bug. ***

Comment 32 mdeggers 2010-12-28 20:26:21 UTC
Commenting from bug 665948:

I did these commands:

find <dir-name> -name \*.so -exec execstack -q {} \;
find <dir-name> -type f -perm /555 -exec execstack -q {} \;

on the following directories:

/lib
/usr/lib
/usr/bin
/var/lib
/usr/sbin
/sbin
/usr/local
/opt

I then used grep to search for a leading X, indicating an executable
stack.

Here's what I found.

/opt/Adobe/Reader9/Reader/intellinux/lib/libcrypto.so
/opt/Adobe/Reader9/Reader/intellinux/lib/libcrypto.so.0.9.8
/opt/Adobe/Reader9/Reader/intellinux/lib/libsccore.so
/opt/javafx-sdk1.3/lib/desktop/libGStreamer.so
/opt/javafx-sdk1.3/emulator/tv/lib/libcvm.so
/opt/real/RealPlayer/codecs/atrc.so
/opt/real/RealPlayer/codecs/colorcvt.so
/opt/real/RealPlayer/codecs/drv2.so
/opt/real/RealPlayer/codecs/drvc.so
/opt/real/RealPlayer/codecs/raac.so
/opt/real/RealPlayer/plugins/swfrender.so
/opt/real/RealPlayer/plugins/vidsite.so
/usr/bin/mono
/usr/bin/par2
/usr/bin/par2create
/usr/bin/par2repair
/usr/bin/par2verify
/usr/lib/libmono.so
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
/usr/lib/libxvidcore.so
/usr/lib/vlc/plugins/codec/libdmo_plugin.so
/usr/lib/vlc/plugins/codec/librealvideo_plugin.so

Most of the files are from RPMs that are not in the Fedora
repositories. I will probably remove RealPlayer from the system since
I don't use it.

However, these files are from RPMs in the Fedora repositories.

/usr/bin/mono
/usr/bin/par2
/usr/bin/par2create
/usr/bin/par2repair
/usr/bin/par2verify
/usr/lib/libmono.so
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so

ls -Z on these files:

-rwxr-xr-x. root root system_u:object_r:mono_exec_t:s0 /usr/bin/mono
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/par2
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/par2create
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/par2repair
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/par2verify
-rwxr-xr-x. root root system_u:object_r:lib_t:s0      
/usr/lib/libmono.so.0.0.0
-rwxr-xr-x. root root system_u:object_r:lib_t:s0      
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so

I don't seem to require the compat-libstdc++-296-2.96-143.i686 package any
more, so I'll remove that and see if this clears up any problems.

Mono and SELinux have been at odds for a long time.

Comment 33 Daniel Walsh 2010-12-28 20:31:16 UTC
Only care about the shared libraries.  Of course you can turn this check off altogether.

setsebool -P allow_execstack 1

Comment 34 Daniel Walsh 2010-12-30 13:35:24 UTC
*** Bug 666303 has been marked as a duplicate of this bug. ***

Comment 35 Daniel Walsh 2010-12-30 13:35:37 UTC
*** Bug 666325 has been marked as a duplicate of this bug. ***

Comment 36 Daniel Walsh 2010-12-30 13:35:50 UTC
*** Bug 666333 has been marked as a duplicate of this bug. ***

Comment 37 Daniel Walsh 2010-12-30 13:40:04 UTC
*** Bug 666218 has been marked as a duplicate of this bug. ***

Comment 38 Daniel Walsh 2010-12-30 13:44:54 UTC
*** Bug 666202 has been marked as a duplicate of this bug. ***

Comment 39 Daniel Walsh 2010-12-30 13:45:37 UTC
*** Bug 666208 has been marked as a duplicate of this bug. ***

Comment 40 Daniel Walsh 2010-12-30 13:53:19 UTC
*** Bug 666200 has been marked as a duplicate of this bug. ***

Comment 41 Daniel Walsh 2010-12-30 13:56:48 UTC
*** Bug 666156 has been marked as a duplicate of this bug. ***

Comment 42 Daniel Walsh 2010-12-30 14:02:31 UTC
*** Bug 665932 has been marked as a duplicate of this bug. ***

Comment 43 Backrow 2010-12-30 18:24:40 UTC
Does just changing the boolean weaken th system?

I get this warning on /usr/bin/nautilus with brasero:

SELinux is preventing /usr/bin/nautilus from using the 'execstack' accesses on a process.

*****  Plugin allow_execstack (53.1 confidence) suggests  ********************

If you do not think /usr/bin/nautilus should need to map stack memory that is both writable and executable.
Then you need to report a bug. This is a potentially dangerous access.
Do
contact your security administrator and report this issue.

*****  Plugin catchall_boolean (42.6 confidence) suggests  *******************

If you want to allow unconfined executables to make their stack executable.  This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla
Then you must tell SELinux about this by enabling the 'allow_execstack' boolean.
Do
setsebool -P allow_execstack 1

*****  Plugin catchall (5.76 confidence) suggests  ***************************

If you believe that nautilus should be allowed execstack access on processes labeled unconfined_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep /usr/bin/nautilus /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

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                Unknown [ process ]
Source                        nautilus
Source Path                   /usr/bin/nautilus
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           brasero-2.32.0-1.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-19.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.10-74.fc14.i686 #1 SMP Thu
                              Dec 23 16:17:40 UTC 2010 i686 i686
Alert Count                   3
First Seen                    Thu 30 Dec 2010 04:16:08 AM EST
Last Seen                     Thu 30 Dec 2010 12:57:36 PM EST
Local ID                      5d573d90-e1dd-4cab-b18a-079666781f4f

Raw Audit Messages
type=AVC msg=audit(1293731856.156:27707): avc:  denied  { execstack } for  pid=2311 comm="brasero" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

nautilus,unconfined_t,unconfined_t,process,execstack
type=SYSCALL msg=audit(1293731856.156:27707): arch=i386 syscall=mprotect success=yes exit=0 a0=bfb30000 a1=1000 a2=1000007 a3=bfb2ef3c items=0 ppid=1 pid=2311 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm=brasero exe=/usr/bin/brasero subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
nautilus,unconfined_t,unconfined_t,process,execstack

#============= unconfined_t ==============
#!!!! This avc can be allowed using the boolean 'allow_execstack'

allow unconfined_t self:process execstack;

Comment 44 Bruce Brackbill 2010-12-30 20:12:58 UTC
What I am experiencing looks be the same bug as this and it affects both Totem and Rhythmbox:


1) Rhythmbox WILL play music but I get the following repeated over and over in /var/log/messages:

Dec 30 12:04:16 localhost setroubleshoot: SELinux is preventing /usr/bin/rhythmbox from using the execstack access on a process. For complete SELinux messages. run sealert -l caac9e83-842e-4604-903a-c57cc1645e39

2) Totem WON'T play any videos and gives the following in /var/log/messages:

Dec 30 11:44:20 localhost setroubleshoot: SELinux is preventing /usr/bin/totem from using the execstack access on a process. For complete SELinux messages. run sealert -l 2a4c79b6-cc4e-4e08-9960-dd61baed30d3

3) The above sealert are the usual... "do you want to alow this? and here is how to do it".  Of course this is of no help to me since I have no idea if I should alow Totem and Rhythmbox execstack access. I can assume I should but you know what assuming does.

4) And When I click on the Selinux Alert Browser I get this in /var/log/messages:

Dec 30 12:01:09 localhost dbus: [system] Rejected send message, 3 matched rules; type="method_call", sender=":1.96" (uid=500 pid=3011 comm="/usr/bin/python) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.97" (uid=0 pid=3013 comm="/usr/bin/python))

Dec 30 12:01:09 localhost setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.97:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched rules; type="method_call", sender=":1.96" (uid=500 pid=3011 comm="/usr/bin/python) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.97" (uid=0 pid=3013 comm="/usr/bin/python))

Comment 45 loedur 2011-01-02 14:20:36 UTC
Hello,

the bug affects me when I try play something with totem.
The SELinux Alert Browser advise me to do the following:
---
You should report this as a bug.
You can generate a local policy module to allow this access.
Allow this access for now by executing:
# grep /usr/libexec/totem-plugin-viewer /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
---

I try to execute the grep instructions with su-rights, but I only get the following message
---
su -c "grep /usr/libexec/totem-plugin-viewer /var/log/audit/audit.log | audit2allow -M mypol"
Password: 
compilation failed:
mypol.te:6:ERROR 'syntax error' at token '' on line 6:


/usr/bin/checkmodule:  error(s) encountered while parsing configuration
/usr/bin/checkmodule:  loading policy configuration from mypol.te
---

What is wrong with my system / instruction call?

Comment 46 shane 2011-01-02 14:57:59 UTC
loedur@web.de

when you 'su -c' you are trying to su to the user "-c" ... probably not right.

you need to do `su - -c 'blah blah'` or `su root -c 'blah blah'`

Comment 47 loedur 2011-01-02 18:33:18 UTC
(In reply to comment #46)
> loedur@web.de
> 
> when you 'su -c' you are trying to su to the user "-c" ... probably not right.
> 
> you need to do `su - -c 'blah blah'` or `su root -c 'blah blah'`

Hello,

I tried with your variants too, but with the same buggy result:

---
su root -c 'grep /usr/libexec/totem-plugin-viewer /var/log/audit/audit.log | audit2allow -M mypol'
Password: 
compilation failed:
mypol.te:6:ERROR 'syntax error' at token '' on line 6:


/usr/bin/checkmodule:  error(s) encountered while parsing configuration
/usr/bin/checkmodule:  loading policy configuration from mypol.te
---
su --c 'grep /usr/libexec/totem-plugin-viewer /var/log/audit/audit.log | audit2allow -M mypol'
Password: 
compilation failed:
mypol.te:6:ERROR 'syntax error' at token '' on line 6:


/usr/bin/checkmodule:  error(s) encountered while parsing configuration
/usr/bin/checkmodule:  loading policy configuration from mypol.te
---

Comment 48 rblnc 2011-01-02 19:15:54 UTC
I am new to Linux and have just installed Fedora.  I get the same SELinux error as well as the same error in comment 45/47 when I execute the grep command in the above syntaxes.

Comment 49 Miroslav Grepl 2011-01-03 14:16:11 UTC
*** Bug 666458 has been marked as a duplicate of this bug. ***

Comment 50 Miroslav Grepl 2011-01-03 14:21:12 UTC
*** Bug 666485 has been marked as a duplicate of this bug. ***

Comment 51 Miroslav Grepl 2011-01-03 14:24:23 UTC
(In reply to comment #48)
> I am new to Linux and have just installed Fedora.  I get the same SELinux error
> as well as the same error in comment 45/47 when I execute the grep command in
> the above syntaxes.

Please use the following command

# setsebool -P allow_execstack 1


We have found a bug in the plugin related to "grep" command.

Comment 52 Joachim Frieben 2011-01-03 14:59:43 UTC
(In reply to comment #51)
What about all the other bugs which have been marked duplicates and which are by no means related to "grep"?

Comment 53 Miroslav Grepl 2011-01-03 15:55:45 UTC
*** Bug 666562 has been marked as a duplicate of this bug. ***

Comment 54 Miroslav Grepl 2011-01-03 15:57:12 UTC
(In reply to comment #52)
> (In reply to comment #51)
> What about all the other bugs which have been marked duplicates and which are
> by no means related to "grep"?

Look at the comment #2, #5.

Comment 55 Miroslav Grepl 2011-01-03 15:58:25 UTC
*** Bug 666571 has been marked as a duplicate of this bug. ***

Comment 56 Miroslav Grepl 2011-01-03 16:48:54 UTC
*** Bug 666638 has been marked as a duplicate of this bug. ***

Comment 57 Miroslav Grepl 2011-01-03 16:49:38 UTC
*** Bug 666639 has been marked as a duplicate of this bug. ***

Comment 58 Miroslav Grepl 2011-01-03 16:50:07 UTC
*** Bug 666652 has been marked as a duplicate of this bug. ***

Comment 59 Daniel Walsh 2011-01-03 20:53:41 UTC
*** Bug 666831 has been marked as a duplicate of this bug. ***

Comment 60 Miroslav Grepl 2011-01-04 13:02:40 UTC
*** Bug 667093 has been marked as a duplicate of this bug. ***

Comment 61 Daniel Walsh 2011-01-04 15:25:27 UTC
*** Bug 666415 has been marked as a duplicate of this bug. ***

Comment 62 Daniel Walsh 2011-01-04 21:15:34 UTC
*** Bug 667212 has been marked as a duplicate of this bug. ***

Comment 63 Daniel Walsh 2011-01-04 21:27:36 UTC
*** Bug 666411 has been marked as a duplicate of this bug. ***

Comment 64 Miroslav Grepl 2011-01-07 14:04:33 UTC
*** Bug 667904 has been marked as a duplicate of this bug. ***

Comment 65 Miroslav Grepl 2011-01-07 14:05:25 UTC
*** Bug 667956 has been marked as a duplicate of this bug. ***

Comment 66 John Reiser 2011-01-07 16:15:03 UTC
The package maintainer can turn off execstack when linking the app by adding "-Wl,-z,noexecstack" to the LDFLAGS (or CFLAGS) in the Makefile.  This takes precedence over .o files or libraries that request execstack, either deliberately or because some .S assembly language file forgot to use ".section .note.GNU-stack,"",@progbits" where the empty attribute string "" turns off execstack.

Comment 67 Daniel Walsh 2011-01-08 15:38:42 UTC
*** Bug 668136 has been marked as a duplicate of this bug. ***

Comment 68 Miroslav Grepl 2011-01-10 09:50:32 UTC
*** Bug 665039 has been marked as a duplicate of this bug. ***

Comment 69 Miroslav Grepl 2011-01-10 09:53:57 UTC
*** Bug 668305 has been marked as a duplicate of this bug. ***

Comment 70 Miroslav Grepl 2011-01-10 10:01:56 UTC
*** Bug 668236 has been marked as a duplicate of this bug. ***

Comment 71 Daniel Walsh 2011-01-10 14:36:17 UTC
*** Bug 668416 has been marked as a duplicate of this bug. ***

Comment 72 Daniel Walsh 2011-01-10 15:56:53 UTC
Some of these might be cured by executing

execstack -c /usr/lib/libxvidcore.so*

Comment 73 Miroslav Grepl 2011-01-12 16:16:02 UTC
*** Bug 669068 has been marked as a duplicate of this bug. ***

Comment 74 Daniel Walsh 2011-01-14 14:26:34 UTC
Wrote a blog on this problem.

http://danwalsh.livejournal.com/38736.html

Comment 75 Dave Jeffery 2011-01-14 15:02:58 UTC
Thanks Dan - thanks to that post I now understand what the problem is, and how to fix it.

Comment 76 Daniel Walsh 2011-01-14 20:32:04 UTC
*** Bug 669800 has been marked as a duplicate of this bug. ***

Comment 77 Al Takishita 2011-01-15 18:38:24 UTC
Dan,
Thanks for the blog.  I was getting messages on usb drives, scanners, and totem.
All work OK.

Thanks again,
Tak

Comment 78 Miroslav Grepl 2011-01-17 09:46:29 UTC
*** Bug 669879 has been marked as a duplicate of this bug. ***

Comment 79 Miroslav Grepl 2011-01-17 11:58:49 UTC
*** Bug 670019 has been marked as a duplicate of this bug. ***

Comment 80 Miroslav Grepl 2011-01-17 12:01:43 UTC
*** Bug 670027 has been marked as a duplicate of this bug. ***

Comment 81 Daniel Walsh 2011-01-17 18:38:52 UTC
Created attachment 473911 [details]
This python program can be used to search for the execstack libraries

I am adding the code from this executable to the allow_execstack plugin.

You can use it now to search for libraries that have the execstack flag set.  Basically the tool takes a path to the source program and uses ldd to list all the libraries used.  It then checks the execstack flag.  It also will take an optional PID if the process is still running, and check the /proc/PID/maps for shared libraries that may have been loaded via dlopen.

findexecstack /usr/bin/pidgin 

Would search for libraries used by pidgin.

Comment 82 Daniel Walsh 2011-01-18 19:10:10 UTC
Created attachment 474129 [details]
Here is the proposed alerts output.

I forced this avc by executing

execstack -s /usr/lib64/libXcomposite.so.1

And then ran pidgin

Comment 83 Daniel Walsh 2011-01-19 21:35:49 UTC
*** Bug 671000 has been marked as a duplicate of this bug. ***

Comment 84 Daniel Walsh 2011-01-21 13:55:44 UTC
*** Bug 671390 has been marked as a duplicate of this bug. ***

Comment 85 Daniel Walsh 2011-01-24 14:06:54 UTC
*** Bug 671898 has been marked as a duplicate of this bug. ***

Comment 86 Daniel Walsh 2011-01-24 15:23:24 UTC
*** Bug 671918 has been marked as a duplicate of this bug. ***

Comment 87 Daniel Walsh 2011-01-24 16:07:40 UTC
*** Bug 671197 has been marked as a duplicate of this bug. ***

Comment 88 Miroslav Grepl 2011-01-31 10:12:23 UTC
*** Bug 673642 has been marked as a duplicate of this bug. ***

Comment 89 Daniel Walsh 2011-02-16 20:21:28 UTC
*** Bug 678123 has been marked as a duplicate of this bug. ***

Comment 90 Daniel Walsh 2011-02-21 16:23:11 UTC
*** Bug 679093 has been marked as a duplicate of this bug. ***

Comment 91 Miroslav Grepl 2011-02-22 11:34:44 UTC
*** Bug 679199 has been marked as a duplicate of this bug. ***

Comment 92 antonio montagnani 2011-02-22 15:10:02 UTC
joining from bug 679199

[antonio@Acer ~]$ find /lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
[antonio@Acer ~]$ find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X 
X /usr/lib/libSDL-1.2.so.0
X /usr/lib/libSDL-1.2.so.0.11.3

Comment 93 antonio montagnani 2011-02-22 15:22:03 UTC
Rolling back to SDL-1.2.14-8.fc14.i686 from the updates-testing makes everything o.k.

Comment 94 Daniel Walsh 2011-02-23 16:23:52 UTC
SDL should not need those flags

Comment 95 Petr Pisar 2011-02-23 17:34:39 UTC
I know, I'm trying to spot what changed in buildroot that tool-chain puts the flag into the ELF. The strange thing is I cannot get non-marked library by compiling previous package release.

In addition I do not know whether the stack should or should not be executable. I have not yet read all the assembler code involved on i686 architecture. I have no hardware to check it out experimentally (e.g. Xvideo routines).

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

Comment 96 Daniel Walsh 2011-02-25 20:45:28 UTC
*** Bug 680540 has been marked as a duplicate of this bug. ***

Comment 97 amreg 2011-02-26 13:01:17 UTC
(In reply to comment #96)
> *** Bug 680540 has been marked as a duplicate of this bug. ***

In fact I get this alert on various programs, all of which are standard Fedora RPMs (audacity, GIMP, Gnash, ...).

But the recent update of SElinux policy (a few days ago) increased the problem dramatically (i.e. just before this policy update, these programs ran fine, but since, all of them yield this alert - and most of which simply do not run at all any more).

I ran "execstack -q" on the executables themselves and always got "-", meaning that they do not require the stack to become executable.
So the problem shoud lie with a common shared library, but up to now I've not found out which one.

(Additionally I discovered that the SELinux Alert browser gets fooled about the reports, but this is another bug and I will file it separately).

Comment 98 amreg 2011-02-26 15:02:28 UTC
(In reply to comment #97)

> I ran "execstack -q" on the executables themselves and always got "-", meaning
> that they do not require the stack to become executable.
> So the problem shoud lie with a common shared library, but up to now I've not
> found out which one.

I found that the likely guilty library is libSDL-1.2.so, so "execstack -c" should be run against that library and not against the main program.

Hope it could help someone.

Additionally, I don't know how the SELinix/libSDL conflict should be resolved in the long term. Is it up to SELinux team to get in touch with le libSDL people to address this issue ? (I simply do not know, sorry).

Comment 99 amreg 2011-02-26 22:42:53 UTC
(In reply to comment #98)

> I found that the likely guilty library is libSDL-1.2.so, so "execstack -c"
> should be run against that library and not against the main program.
> 
> Hope it could help someone.
> 
> Additionally, I don't know how the SELinix/libSDL conflict should be resolved
> in the long term. Is it up to SELinux team to get in touch with le libSDL
> people to address this issue ? (I simply do not know, sorry).

Apparently, the libSDL people have fixed their issue (https://bugzilla.redhat.com/show_bug.cgi?id=678818).

Comment 100 Daniel Walsh 2011-03-07 22:04:47 UTC
*** Bug 663884 has been marked as a duplicate of this bug. ***

Comment 101 Daniel Walsh 2011-03-07 22:42:18 UTC
*** Bug 682824 has been marked as a duplicate of this bug. ***

Comment 102 Daniel Walsh 2011-03-11 15:29:45 UTC
*** Bug 674739 has been marked as a duplicate of this bug. ***

Comment 103 Daniel Walsh 2011-03-21 22:19:49 UTC
*** Bug 689362 has been marked as a duplicate of this bug. ***

Comment 104 Daniel Walsh 2011-04-08 18:20:06 UTC
*** Bug 694342 has been marked as a duplicate of this bug. ***

Comment 105 Daniel Walsh 2011-04-14 13:31:07 UTC
*** Bug 696544 has been marked as a duplicate of this bug. ***

Comment 106 Daniel Walsh 2011-04-17 09:31:07 UTC
*** Bug 697170 has been marked as a duplicate of this bug. ***

Comment 107 Daniel Walsh 2011-04-29 15:05:17 UTC
*** Bug 654173 has been marked as a duplicate of this bug. ***

Comment 108 Miroslav Grepl 2011-05-02 10:30:31 UTC
*** Bug 701147 has been marked as a duplicate of this bug. ***

Comment 109 Daniel Walsh 2011-08-11 20:14:42 UTC
*** Bug 246171 has been marked as a duplicate of this bug. ***

Comment 110 Daniel Walsh 2012-01-24 15:41:28 UTC
*** Bug 784144 has been marked as a duplicate of this bug. ***


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