Description of problem: SELinux is preventing knotify4 from making the program stack executable. Version-Release number of selected component (if applicable): Source RPM Packages kdebase-runtime-4.2.90-1.fc12 Policy RPM selinux-policy-3.6.15-1.fc12 How reproducible: always Steps to Reproduce: 1.login to kde 2. 3. Actual results: avc Expected results: no avc Additional info: Summary: SELinux is preventing knotify4 from making the program stack executable. Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] The knotify4 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 knotify4 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 (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. 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 knotify4 to run correctly, you can change the context of the executable to execmem_exec_t. "chcon -t execmem_exec_t '/usr/bin/knotify4'" 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/knotify4'" Fix Command: chcon -t execmem_exec_t '/usr/bin/knotify4' Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0 Target Context unconfined_u:unconfined_r:unconfined_t:s0 Target Objects None [ process ] Source knotify4 Source Path /usr/bin/knotify4 Port <Unknown> Host jerry-opti755 Source RPM Packages kdebase-runtime-4.2.90-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.15-1.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name allow_execstack Host Name jerry-opti755 Platform Linux jerry-opti755 2.6.30-0.1.2.32.rc8.xendom0.fc12.x86_64 #1 SMP Thu Jun 4 17:46:39 EDT 2009 x86_64 x86_64 Alert Count 2 First Seen Mon 15 Jun 2009 11:43:53 AM CDT Last Seen Mon 15 Jun 2009 11:43:53 AM CDT Local ID 17a38427-0110-46f7-97f1-b027e3e2b40a Line Numbers Raw Audit Messages node=jerry-opti755 type=AVC msg=audit(1245084233.76:40438): avc: denied { execstack } for pid=3996 comm="knotify4" scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process node=jerry-opti755 type=AVC msg=audit(1245084233.76:40438): avc: denied { execmem } for pid=3996 comm="knotify4" scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process node=jerry-opti755 type=SYSCALL msg=audit(1245084233.76:40438): arch=c000003e syscall=10 success=yes exit=0 a0=7fffbafe1000 a1=1000 a2=1000007 a3=361621a121 items=0 ppid=1 pid=3996 auid=2355 uid=2355 gid=100 euid=2355 suid=2355 fsuid=2355 egid=100 sgid=100 fsgid=100 tty=(none) ses=1 comm="knotify4" exe="/usr/bin/knotify4" subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null)
This is most likely caused by the same shared library as bug 506122.
CCing dwalsh: Any idea how we can figure out which shared object is actually at fault here? Short of manually running readelf on every single shared library on the system?
I've also started seeing denials in k3b after I installed k3b-extras-freeworld from RPM Fusion. Jun 29 08:51:29 localhost kernel: k3b used greatest stack depth: 1800 bytes left Jun 30 16:30:34 localhost yum: Installed: k3b-debuginfo-1.66.0-3.fc12.x86_64 Jul 2 10:01:26 localhost kernel: k3b used greatest stack depth: 2216 bytes left Jul 2 10:09:56 localhost yum: Installed: k3b-extras-freeworld-1.66.0-0.1.alpha2.fc12.x86_64 Jul 2 10:10:08 localhost setroubleshoot: SELinux is preventing k3b from making the program stack executable. For complete SELinux messages. run sealert -l 513286f9-c64d-4875-8f7f-d46884e646a7 Jul 2 10:10:08 localhost setroubleshoot: SELinux is preventing k3b from making the program stack executable. For complete SELinux messages. run sealert -l 513286f9-c64d-4875-8f7f-d46884e646a7
Not reproducible by me (on f11/x86_64 anyway), you happen to have any binary blobs and/or w32codecs installed?
[root@jerry-opti755 ~]# sealert -l 513286f9-c64d-4875-8f7f-d46884e646a7 Summary: SELinux is preventing k3b from making the program stack executable. Detailed Description: The k3b 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 k3b 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 (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. 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 k3b to run correctly, you can change the context of the executable to execmem_exec_t. "chcon -t execmem_exec_t '/usr/bin/k3b'" 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/k3b'" Fix Command: chcon -t execmem_exec_t '/usr/bin/k3b' Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0 Target Context unconfined_u:unconfined_r:unconfined_t:s0 Target Objects None [ process ] Source knotify4 Source Path /usr/bin/knotify4 Port <Unknown> Host jerry-opti755 Source RPM Packages k3b-1.66.0-3.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.20-2.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execstack Host Name jerry-opti755 Platform Linux jerry-opti755 2.6.30-0.1.2.32.rc8.xendom0.fc12.x86_64 #1 SMP Thu Jun 4 17:46:39 EDT 2009 x86_64 x86_64 Alert Count 8 First Seen Mon Jun 29 11:34:52 2009 Last Seen Thu Jul 2 10:10:08 2009 Local ID 513286f9-c64d-4875-8f7f-d46884e646a7 Line Numbers Raw Audit Messages node=jerry-opti755 type=AVC msg=audit(1246547408.331:38822): avc: denied { execstack } for pid=5568 comm="k3b" scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process node=jerry-opti755 type=SYSCALL msg=audit(1246547408.331:38822): arch=c000003e syscall=10 success=no exit=-13 a0=7fffef228000 a1=1000 a2=1000007 a3=361621a121 items=0 ppid=4036 pid=5568 auid=2355 uid=2355 gid=100 euid=2355 suid=2355 fsuid=2355 egid=100 sgid=100 fsgid=100 tty=pts2 ses=1 comm="k3b" exe="/usr/bin/k3b" subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null)
These may or may not be related, but as the original report pertained to knotify4, not k3b, I'd suggest a separate bug.
(In reply to comment #6) > These may or may not be related, but as the original report pertained to > knotify4, not k3b, I'd suggest a separate bug. I can do that, but note: 1. /usr/bin/knotify4 is also the source for the k3b alert, and 2. the root cause may be the same here as in #506122
Sorry, I'm blind, I didn't (and don't) see any references to knotify in the k3b alert. oh well, but you're probably right about the relation between these bugs. Didn't answer my question in comment #4 yet though.
*** Bug 509496 has been marked as a duplicate of this bug. ***
Ping? Anyone have any ideas on this one. -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Rex, Kevin what do we want to do with this and other selinux issues? -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 521918 has been marked as a duplicate of this bug. ***
Re: comment #11 Kinda stuck I guess, we can't reproduce, and the help we've asked from the selinux folks has been largely fruitless. One guess (based largely on past experience) is that there's 3rd party software causing it, like binary nvidia drivers or codecs have in the past.
(In reply to comment #13) > One guess (based largely on past experience) is that there's 3rd party software > causing it, like binary nvidia drivers or codecs have in the past. 1. I don't have binary nvidia drivers, 2. I don't believe codecs have something to do here, immediately after KDE login, when there are no applications started.
knotify4 uses Phonon which uses xine-lib or GStreamer which both load codecs.
So if you want to use these you will either need to turn the protection off using the boolean. We can not fix closed source plugins/codecs.
The codecs idea was only a theory, not fact (yet, afaict).
nevermind, reclosing, unless there's evidence to the contrary that these machines contain fedora only software (reporters, please chime in if that is so). *** This bug has been marked as a duplicate of bug 506122 ***