SELinux is preventing /usr/sbin/monitor-get-edid-using-vbe from 'mmap_zero' accesses on the memprotect Unknown. ***** Plugin mmap_zero (53.1 confidence) suggests ************************** If you do not think /usr/sbin/monitor-get-edid-using-vbe 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. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests *************************** If you believe that monitor-get-edid-using-vbe should be allowed mmap_zero access on the Unknown 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 monitor-get-edi /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 [ memprotect ] Source monitor-get-edi Source Path /usr/sbin/monitor-get-edid-using-vbe Port <Unknown> Host (removed) Source RPM Packages monitor-edid-3.0-1.fc13 Target RPM Packages Policy RPM selinux-policy-3.9.7-44.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.35.14-96.fc14.i686.PAE #1 SMP Thu Sep 1 12:31:46 UTC 2011 i686 i686 Alert Count 1 First Seen Sat 01 Oct 2011 10:34:57 AM CDT Last Seen Sat 01 Oct 2011 10:34:57 AM CDT Local ID 4618b8a5-697d-4da8-abd2-9d44b46fd6bd Raw Audit Messages type=AVC msg=audit(1317483297.980:62970): avc: denied { mmap_zero } for pid=17045 comm="monitor-get-edi" 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(1317483297.980:62970): arch=i386 syscall=mmap2 success=no exit=EACCES a0=f000 a1=502 a2=7 a3=11 items=0 ppid=17044 pid=17045 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm=monitor-get-edi exe=/usr/sbin/monitor-get-edid-using-vbe subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash: monitor-get-edi,unconfined_t,unconfined_t,memprotect,mmap_zero audit2allow #============= unconfined_t ============== #!!!! This avc is allowed in the current policy allow unconfined_t self:memprotect mmap_zero; audit2allow -R #============= unconfined_t ============== #!!!! This avc is allowed in the current policy allow unconfined_t self:memprotect mmap_zero;
All of the software involved came from fedora repositories.
Looks like we may need to confine /usr/sbin/monitor-get-edid-using-vbe, but that does not help unconfined users... This is my personal opinion but: unconfined users should probably "setsebool -P mmap_low_allowed 1 (or have it set to that by default)" or move to a confined user domain. http://danwalsh.livejournal.com/30084.html?thread=211844
I believe setsebool -P mmap_low_allowed 1 is enough for this issue. This relates with vbe.
We got You Tube videos because we allow mmap_zero to unconfined users. There is little reason any app should need this protection.
*** Bug 1285801 has been marked as a duplicate of this bug. ***