SELinux reports the following. Strangely there's no offer to file to bug for me, so I'm doing it manually since it seems to be the really important one. Summary Your system may be seriously compromised! Detailed Description SELinux has denied the vbetool the ability to mmap low area of the kernel address space. The ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Preventing such mappings helps protect against exploiting null deref bugs in the kernel. All applications that need this access should have already had policy written for them. If a compromised application tries modify the kernel this AVC would be generated. This is a serious issue. Your system may very well be compromised. Allowing Access Contact your security administrator and report this issue. Additional Information Source Context: system_u:system_r:vbetool_t:s0-s0:c0.c1023 Target Context: system_u:system_r:vbetool_t:s0-s0:c0.c1023 Target Objects: None [ memprotect ] Source: vbetool Source Path: /usr/sbin/vbetool Port: <Unknown> Host: moose.localdomain Source RPM Packages: vbetool-1.2.1-1.fc12 Target RPM Packages: Policy RPM: selinux-policy-3.6.26-8.fc12 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: mmap_zero Host Name: moose.localdomain Platform: Linux moose.localdomain 2.6.31-0.125.4.2.rc5.git2.fc12.x86_64 #1 SMP Tue Aug 11 21:00:45 EDT 2009 x86_64 x86_64 Alert Count: 7 First Seen: Thu 20 Aug 2009 11:44:00 EST Last Seen: Thu 20 Aug 2009 11:44:12 EST Local ID: f0c456bd-5a76-4541-b734-d5c2a45c1681 Line Numbers: Raw Audit Messages : node=moose.localdomain type=AVC msg=audit(1250732652.756:30): avc: denied { mmap_zero } for pid=1647 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect node=moose.localdomain type=SYSCALL msg=audit(1250732652.756:30): arch=c000003e syscall=9 success=yes exit=0 a0=0 a1=502 a2=7 a3=11 items=0 ppid=1631 pid=1647 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vbetool" exe="/usr/sbin/vbetool" subj=system_u:system_r:vbetool_t:s0-s0:c0.c1023 key=(null)
Ooops, that should be rawhide.
We want to stop the ability to mmap_zero applications by default. What happens if vbetool can not mmap_zero on boot?
mapping 0 is required for vm86 mode, which we don't use. Given that we're running under x86emu we could presumably copy the low memory to somewhere arbitrary and then provide an offset - I have a vague recollection that x86emu even supports that already. As for right now, though, the effect of denying that is that vbetool stops working.
Adam, if we don't need this can we stop doing it?
*** Bug 518484 has been marked as a duplicate of this bug. ***
vbetool itself is okay in this regard, it only maps the VROM, and while it does do so at a fixed address, it's not the zero page. libx86, however, maps at 0. You'd kind of like some new LRMI API to tell the library about maps you've set up: void *LRMI_add_map(void *map, uint32_t base, uint32_t size); and then have x_outl() and friends in thunk.c walk the list of maps. Which is more or less what X does internally. (The return value is really only for if you want to delete maps at runtime, which... might be overdesigning it.)
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
is this a regression of BUG435935?, I am getting this reported every time at boot in a F12 system with using an Nvidia GeForce 6150SE nForce 43 card with KMS enabled : Nov 16 23:01:35 inspiron kernel: type=1400 audit(1258441289.509:4): avc: denied { mmap_zero } for pid=408 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
Arenas for now you need to set the mmap_low_allowed to on. setsebool -P mmap_low_allowed 1
libx86-1.1-9.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libx86-1.1-9.fc12
libx86-1.1-9.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libx86'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11717
This update never made it past testing and for me, it didn't solve the problem. On my Nvidia ION box with proprietary nvidia drivers, X11 will not start on boot in enforcing mode. If I boot with 'enforcing=0' and add 'setenforce enforcing' in /etc/rc.local, X11 will start because vbetool will have run successfully. Note I don't get an alert because so early in the boot process, auditd is not running. If I boot in enforcing mode with boolean mmap_low_allowed = true, X11 starts. Updating to this testing package did not change the above results. Running 'vbetool vbemode get' results in: mmap /dev/mem: Permission denied Failed to initialise LRMI (Linux Real-Mode Interface). and the following audits: type=AVC msg=audit(1266896592.519:145): avc: denied { mmap_zero } for pid=18445 comm="vbetool" scontext=unconfined_u:unconfined_r:vbetool_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect type=SYSCALL msg=audit(1266896592.519:145): arch=40000003 syscall=192 success=no exit=-13 a0=f000 a1=502 a2=7 a3=11 items=0 ppid=18368 pid=18445 auid=18183 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=2 comm="vbetool" exe="/usr/sbin/vbetool" subj=unconfined_u:unconfined_r:vbetool_t:s0-s0:c0.c1023 key=(null) Let me know if I can help further.
I'm seeing this in dmesg when booting f13 and it looks similar: type=1400 audit(1269303288.719:3): avc: denied { read } for pid=555 comm="readahead" name="sda8" dev=devtmpfs ino=5825 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=blk_file type=1400 audit(1269303288.719:4): avc: denied { open } for pid=555 comm="readahead" name="sda8" dev=devtmpfs ino=5825 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=blk_file udev: starting version 151 type=1400 audit(1269303290.667:5): avc: denied { mmap_zero } for pid=622 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
Miroslav, add fs_dontaudit_read_tmpfs_blk_dev(readahead_t) ######################################## ## <summary> ## dontaudit Read and write block nodes on tmpfs filesystems. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`fs_dontaudit_read_tmpfs_blk_dev',` gen_require(` type tmpfs_t; ') dontaudit $1 tmpfs_t:blk_file read_blk_file_perms; ') To eliminate first two avc messages.
I don't have f12 to test on anymore. Is the issue in f13 I see in dmesg the same. If it is, then this is still an issue in f13 with libx86-1.1-9.fc13.x86_64. Otherwise I'm not going to be much help.
See bug 530065 but I'm crossposting my F14 experience here since the owner of this bug is different: Getting this error on FC14 Beta RC3 ----------------------------------- Sep 21 23:07:34 localhost kernel: type=1400 audit(1285128448.952:4): avc: denied { mmap_zero } for pid=566 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect Sep 21 23:11:10 localhost kernel: type=1400 audit(1285128662.127:4): avc: denied { mmap_zero } for pid=563 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect --------------------------------------- Sep 21 23:07:34 localhost kernel: type=1400 audit(1285128448.952:4): avc: denied { mmap_zero } for pid=566 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect Was caused by: The boolean mmap_low_allowed was set incorrectly. Description: Control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Allow access by executing: # setsebool -P mmap_low_allowed 1 Sep 21 23:11:10 localhost kernel: type=1400 audit(1285128662.127:4): avc: denied { mmap_zero } for pid=563 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect Was caused by: The boolean mmap_low_allowed was set incorrectly. Description: Control the ability to mmap a low area of the address space, as configured by /proc/sys/kernel/mmap_min_addr. Allow access by executing: # setsebool -P mmap_low_allowed 1 --------------------------------------- kernel-2.6.35.4-28.fc14.x86_64 selinux-policy-targeted-3.9.3-4.fc14.noarch vbetool-1.2.2-1.fc12.x86_64 libx86-1.1-9.fc13.x86_64
libx86-1.1-9.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.