Description of problem: SELinux is preventing /usr/libexec/clock-applet from 'mmap_zero' accesses on the memprotect . ***** Plugin mmap_zero (53.1 confidence) suggests ************************** If you do not think /usr/libexec/clock-applet should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ******************* If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. You can read 'unconfined_selinux' man page for more details. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests *************************** If you believe that clock-applet should be allowed mmap_zero access on the memprotect 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 clock-applet /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 [ memprotect ] Source clock-applet Source Path /usr/libexec/clock-applet Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.11.1-97.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.9.6-200.fc18.i686 #1 SMP Thu Jun 13 19:29:40 UTC 2013 i686 i686 Alert Count 8 First Seen 2013-07-06 00:09:10 EDT Last Seen 2013-07-06 00:09:10 EDT Local ID 4474d966-11d7-4d4e-b521-a046f31b12ce Raw Audit Messages type=AVC msg=audit(1373083750.173:37105): avc: denied { mmap_zero } for pid=22561 comm="clock-applet" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect Hash: clock-applet,unconfined_t,unconfined_t,memprotect,mmap_zero audit2allow #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'mmap_low_allowed' allow unconfined_t self:memprotect mmap_zero; audit2allow -R require { type unconfined_t; class memprotect mmap_zero; } #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'mmap_low_allowed' allow unconfined_t self:memprotect mmap_zero; Additional info: reporter: libreport-2.1.5 hashmarkername: setroubleshoot kernel: 3.9.6-200.fc18.i686 type: libreport
Where did /usr/libexec/clock-applet come from? It should not be requesting this access.
Without auditd running and collecting the syscall record in question it's impossible to tell if this is an application bug or if this should be a dup of the general kernel bug. Can you reproduce? If so, please let us know how. If not, we should consider duping this bug...
It came from: % rpm -q --whatprovides /usr/libexec/clock-applet gnome-panel-3.6.2-2.fc18.i686 This is a fully patched fc18 install.
according to the output of: /bin/systemctl status auditd.service auditd is running and has been doing so for more than a week. is there a grep or a processor you need me to run and add to the ticket?
Get the output of Can you get it to happen after execute auditctl -w /etc/shadow THen collect the avc info with ausearch -m avc -ts recent
The fact this has only every been reported once makes me feel quite sure this is a dup of https://bugzilla.redhat.com/show_bug.cgi?id=490753 *** This bug has been marked as a duplicate of bug 490753 ***