Bug 518351 - vbetool should stop mmap'ing the zero page
Summary: vbetool should stop mmap'ing the zero page
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libx86
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Matthew Garrett
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 518484 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-20 01:54 UTC by Rodd Clarkson
Modified: 2013-01-10 08:01 UTC (History)
11 users (show)

Fixed In Version: libx86-1.1-9.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-11 19:22:08 UTC


Attachments (Terms of Use)

Description Rodd Clarkson 2009-08-20 01:54:35 UTC
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)

Comment 1 Rodd Clarkson 2009-08-20 02:00:07 UTC
Ooops, that should be rawhide.

Comment 2 Daniel Walsh 2009-08-20 13:04:52 UTC
We want to stop the ability to mmap_zero applications by default.  What happens if vbetool can not mmap_zero on boot?

Comment 3 Matthew Garrett 2009-08-20 14:07:02 UTC
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.

Comment 4 Daniel Walsh 2009-08-20 16:16:52 UTC
Adam, if we don't need this can we stop doing it?

Comment 5 Daniel Walsh 2009-08-20 16:24:21 UTC
*** Bug 518484 has been marked as a duplicate of this bug. ***

Comment 6 Adam Jackson 2009-08-27 17:58:22 UTC
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.)

Comment 7 Bug Zapper 2009-11-16 11:33:26 UTC
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

Comment 8 Arenas Belon, Carlo Marcelo 2009-11-17 09:14:28 UTC
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

Comment 9 Daniel Walsh 2009-11-17 13:42:14 UTC
Arenas for now you need to set the mmap_low_allowed to on.

setsebool -P mmap_low_allowed 1

Comment 10 Fedora Update System 2009-11-17 19:45:16 UTC
libx86-1.1-9.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/libx86-1.1-9.fc12

Comment 11 Fedora Update System 2009-11-20 05:11:52 UTC
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

Comment 12 Chris Schanzle 2010-02-23 03:47:09 UTC
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.

Comment 13 Rodd Clarkson 2010-03-23 00:40:06 UTC
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

Comment 14 Daniel Walsh 2010-03-23 12:01:19 UTC
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.

Comment 15 Rodd Clarkson 2010-07-17 00:03:51 UTC
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.

Comment 16 John Watzke 2010-09-24 12:50:14 UTC
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

Comment 17 Fedora Update System 2010-10-11 19:21:55 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.