Bug 652297 (allow_execstack)
| Summary: | SELinux is preventing /usr/bin/gcm-session from making the program stack executable. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrea Dell'Amico <adellam> | ||||||
| Component: | SDL | Assignee: | Thomas Woerner <twoerner> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 14 | CC: | ACiDGRiM, amreg.redhat, anton.avdonin, antonio.montagnani, archawka, backrowbugzilla, bagal81, beland, bignikita, blackcode, brackbillbruce, bruno, bugsrep, bugzilla, cedpren, charles.e.collins, chedi.toueiti, craig_horrocks, crustie.lindblom, csotto, david.bobroff, david.deaderick, david.richard.jeffery, dilworthscott, drepper, dwalsh, edneymatias, ek7ki, emanmc, evilastharoth, f.demiralp, gerfert, jamundso, janezja, jason, jfrieben, jmj.buckley, johnmargaritopoulos, jp.grossglauser, jreiser, kazimsarikaya, kostassf, kryukov, loedur, luya, mads, mahazmi_mahadi, mdeggers, me, medsoft_objects, meyer, mgrepl, michael, michal, nikolas.moraitis, n.underwood78, pahan, pavel.aronsky, pmvr, ppisar, ralf.schneider, rblnc, reelkaas, reykvid, rhughes, richard, rtekel, sebasst.f, shanewbbr, simon, sjdp, ssabcew, starship.enterprise, stooggy, superman_is_deady, tak_hmb, twoerner, vamyur, vesselam, wind_of_eternity, yukio.adamczyk, zahidsahar016 | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | setroubleshoot_trace_hash:fe151899c2d6e280d2e1a8f1a02ed0ce540991580e5325ba8b6cb353a38ed775 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-02-23 17:34:39 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: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrea Dell'Amico
2010-11-11 15:28:10 UTC
*** This bug has been marked as a duplicate of bug 533987 *** You have to either set the label to execmem_exec_t or turn the check off #setsebool -P allow_execstack 1 I think we had this bug before on gcm-coller-manager? What would be the root cause of it needing execstack? Something like overrunning a buffer that would be picked up on valgrind? Thanks. 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
(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? I think this might be specific to Andrea's machine. Andrea are you running nvidia drivers? 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? 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. Printing still works, and no more SELinux alerts from gcm-session. Thanks to all, Andrea 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. I'll do, thanks. The driver is a tar file that contains the libraries and some scripts, SELinux is completely ignored. 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. 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. *** Bug 654068 has been marked as a duplicate of this bug. *** *** Bug 655131 has been marked as a duplicate of this bug. *** *** Bug 655362 has been marked as a duplicate of this bug. *** *** Bug 655353 has been marked as a duplicate of this bug. *** *** Bug 657786 has been marked as a duplicate of this bug. *** *** Bug 657708 has been marked as a duplicate of this bug. *** *** Bug 657949 has been marked as a duplicate of this bug. *** *** Bug 658708 has been marked as a duplicate of this bug. *** *** Bug 660068 has been marked as a duplicate of this bug. *** *** Bug 660146 has been marked as a duplicate of this bug. *** *** Bug 661807 has been marked as a duplicate of this bug. *** *** Bug 662609 has been marked as a duplicate of this bug. *** *** Bug 663505 has been marked as a duplicate of this bug. *** *** Bug 665948 has been marked as a duplicate of this bug. *** *** Bug 642673 has been marked as a duplicate of this bug. *** *** Bug 666069 has been marked as a duplicate of this bug. *** *** Bug 665458 has been marked as a duplicate of this bug. *** 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. Only care about the shared libraries. Of course you can turn this check off altogether. setsebool -P allow_execstack 1 *** Bug 666303 has been marked as a duplicate of this bug. *** *** Bug 666325 has been marked as a duplicate of this bug. *** *** Bug 666333 has been marked as a duplicate of this bug. *** *** Bug 666218 has been marked as a duplicate of this bug. *** *** Bug 666202 has been marked as a duplicate of this bug. *** *** Bug 666208 has been marked as a duplicate of this bug. *** *** Bug 666200 has been marked as a duplicate of this bug. *** *** Bug 666156 has been marked as a duplicate of this bug. *** *** Bug 665932 has been marked as a duplicate of this bug. *** 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;
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)) 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? loedur 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'` (In reply to comment #46) > loedur > > 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 --- 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. *** Bug 666458 has been marked as a duplicate of this bug. *** *** Bug 666485 has been marked as a duplicate of this bug. *** (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. (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"? *** Bug 666562 has been marked as a duplicate of this bug. *** (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. *** Bug 666571 has been marked as a duplicate of this bug. *** *** Bug 666638 has been marked as a duplicate of this bug. *** *** Bug 666639 has been marked as a duplicate of this bug. *** *** Bug 666652 has been marked as a duplicate of this bug. *** *** Bug 666831 has been marked as a duplicate of this bug. *** *** Bug 667093 has been marked as a duplicate of this bug. *** *** Bug 666415 has been marked as a duplicate of this bug. *** *** Bug 667212 has been marked as a duplicate of this bug. *** *** Bug 666411 has been marked as a duplicate of this bug. *** *** Bug 667904 has been marked as a duplicate of this bug. *** *** Bug 667956 has been marked as a duplicate of this bug. *** 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. *** Bug 668136 has been marked as a duplicate of this bug. *** *** Bug 665039 has been marked as a duplicate of this bug. *** *** Bug 668305 has been marked as a duplicate of this bug. *** *** Bug 668236 has been marked as a duplicate of this bug. *** *** Bug 668416 has been marked as a duplicate of this bug. *** Some of these might be cured by executing execstack -c /usr/lib/libxvidcore.so* *** Bug 669068 has been marked as a duplicate of this bug. *** Wrote a blog on this problem. http://danwalsh.livejournal.com/38736.html Thanks Dan - thanks to that post I now understand what the problem is, and how to fix it. *** Bug 669800 has been marked as a duplicate of this bug. *** Dan, Thanks for the blog. I was getting messages on usb drives, scanners, and totem. All work OK. Thanks again, Tak *** Bug 669879 has been marked as a duplicate of this bug. *** *** Bug 670019 has been marked as a duplicate of this bug. *** *** Bug 670027 has been marked as a duplicate of this bug. *** 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.
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
*** Bug 671000 has been marked as a duplicate of this bug. *** *** Bug 671390 has been marked as a duplicate of this bug. *** *** Bug 671898 has been marked as a duplicate of this bug. *** *** Bug 671918 has been marked as a duplicate of this bug. *** *** Bug 671197 has been marked as a duplicate of this bug. *** *** Bug 673642 has been marked as a duplicate of this bug. *** *** Bug 678123 has been marked as a duplicate of this bug. *** *** Bug 679093 has been marked as a duplicate of this bug. *** *** Bug 679199 has been marked as a duplicate of this bug. *** 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 Rolling back to SDL-1.2.14-8.fc14.i686 from the updates-testing makes everything o.k. SDL should not need those flags 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 *** *** Bug 680540 has been marked as a duplicate of this bug. *** (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). (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). (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). *** Bug 663884 has been marked as a duplicate of this bug. *** *** Bug 682824 has been marked as a duplicate of this bug. *** *** Bug 674739 has been marked as a duplicate of this bug. *** *** Bug 689362 has been marked as a duplicate of this bug. *** *** Bug 694342 has been marked as a duplicate of this bug. *** *** Bug 696544 has been marked as a duplicate of this bug. *** *** Bug 697170 has been marked as a duplicate of this bug. *** *** Bug 654173 has been marked as a duplicate of this bug. *** *** Bug 701147 has been marked as a duplicate of this bug. *** *** Bug 246171 has been marked as a duplicate of this bug. *** *** Bug 784144 has been marked as a duplicate of this bug. *** |