On 04/23/2013 07:30 PM, Beartooth wrote:
On Tue, 23 Apr 2013 17:44:33 +0100, Junk wrote:
Try sealert -a /var/log/audit/audit.log
[root@Hbsk2 ~]# sealert -a /var/log/audit/audit.log 12% done[Errno 2] No such file or directory: 'wine-preloader' 100% donefound 3 alerts in /var/log/audit/audit.log
[snip]
SELinux is preventing /usr/bin/arora from mmap_zero access on the memprotect .
***** Plugin mmap_zero (53.1 confidence) suggests
If you do not think /usr/bin/arora 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 mmap_low_allowed 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 arora 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 arora /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 arora Source Path /usr/bin/arora Port <Unknown> Host <Unknown> Source RPM Packages arora-0.11.0-4.fc17.i686 Target RPM Packages Policy RPM selinux-policy-3.10.0-167.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name Hbsk2.hsd1.va.comcast.net Platform Linux Hbsk2.hsd1.va.comcast.net 3.8.4-102.fc17.i686.PAE #1 SMP Sun Mar 24 13:15:17 UTC 2013 i686 i686 Alert Count 1 First Seen 2013-04-21 16:01:52 EDT Last Seen 2013-04-21 16:01:52 EDT Local ID fedad9e7-5ad4-49b0-a517-15a1e9efd7d4
Raw Audit Messages type=AVC msg=audit(1366574512.695:480): avc: denied { mmap_zero } for pid=25852 comm="arora" scontext=unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 tclass=memprotect
type=SYSCALL msg=audit(1366574512.695:480): arch=i386 syscall=mmap2 success=no exit=EACCES a0=0 a1=7000 a2=3 a3=4022 items=0 ppid=1 pid=25852 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=2 tty=(none) comm=arora exe=/usr/bin/arora subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Hash: arora,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
#============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'mmap_low_allowed'
allow unconfined_t self:memprotect mmap_zero;
[root@Hbsk2 ~]#
Or
grep setroubleshoot /var/log/messages
There will have been a full report in the graphical tool that initially warned you but these should give the same result.
They don't -- this one gets
[root@Hbsk2 ~]# grep setroubleshoot /var/log/messages Apr 21 16:02:00 Hbsk2 setroubleshoot: SELinux is preventing /usr/bin/arora from mmap_zero access on the memprotect . For complete SELinux messages. run sealert -l 6805396b-b8d1-4368-9356-aef00cbb2e43 Apr 22 14:57:12 Hbsk2 setroubleshoot: Plugin Exception wine Apr 22 14:57:12 Hbsk2 setroubleshoot: SELinux is preventing wine-preloader from mmap_zero access on the memprotect . For complete SELinux messages. run sealert -l 78752ead-8351-4d64-a04d-a2f500d942cd [root@Hbsk2 ~]#
Excellent work. Looks good. The audit.log reports are the long form of the messages in /var/log/messages If you copied and pasted ""sealert -l 6805396b-b8d1-4368-9356-aef00cbb2e43" then it would show you the exact same message that's in the audit.log, The salient part being
SELinux is preventing /usr/bin/arora from mmap_zero access on the memprotect
It's possible that one of your tabs had a page that was trying to exploit your browser to access a region of low memory in the kernel.
It also might be something much more mundane such as a bug in the browser which occurs when you have 100+ tabs open and tries to write to a misaddressed memory region.
Either way I can't imagine having a web browser writing into odd bits of kernel memory is a good idea and it would appear to be a good thing that SELinux stopped it. If it keeps happening when you have lots of tabs I'd file a bug in Bugzilla against arora.
There seems to be a wine app trying to do a similar thing. This appears to be more common and there is a wine-specific boolean to manage it.
setsebool -P wine_mmap_zero_ignore 1
Junk