Bug 433447 - intel driver does not work with selinux=enforce
intel driver does not work with selinux=enforce
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2008-02-19 06:42 EST by Christian Jung
Modified: 2008-02-19 11:41 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-19 11:41:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Christian Jung 2008-02-19 06:42:25 EST
Description of problem:
After upgrading to the newest X11 and kernel packages, X11 won't start if
SELinux is set to enforcing.

Version-Release number of selected component (if applicable):

How reproducible:
always if selinux=enforcing

Steps to Reproduce:
1. upgrade to these new packages
2. make sure SELinux is set to enforcing mode
3. restart gdm
Actual results:
gdm tries to start X but fails

Expected results:
gdm should be able to start X

Additional info:
If startx is used, X11 starts without any error message.

Here are the interesting entries from audit.log:
type=AVC msg=audit(1203418251.920:89): avc:  denied  { mmap_zero } for  pid=4095
 comm="Xorg" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:s
ystem_r:xdm_t:s0-s0:c0.c1023 tclass=memprotect
type=SYSCALL msg=audit(1203418251.920:89): arch=40000003 syscall=117 success=no 
exit=-13 a0=15 a1=20000 a2=2000 a3=bfeb2b08 items=0 ppid=4091 pid=4095 auid=4294
967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty7 ses=4294
967295 comm="Xorg" exe="/usr/bin/Xorg" subj=system_u:system_r:xdm_t:s0-s0:c0.c10
23 key=(null)
Comment 1 Adam Jackson 2008-02-19 11:32:20 EST
mmap_zero is a new bit of policy that prevents userspace processes from mapping
pages into the low ~64k of address space (actually a tunable number based on a
sysctl).  This ensures that null-pointer dereferences within the kernel really
do cause segfaults, which is otherwise a potential security issue.

The X server requires this permission on x86 systems under RHEL5, because they
use the VM86 processor mode to execute VESA BIOS calls (including posting
non-primary heads), and VM86 mode is crippled such that it _has_ to run in the
low 1M of address space, which includes having the low 4k mapped as that's where
the interrupt vector table lives.  On all other architectures, this is achieved
with an x86 real mode emulator that runs in an emulated address space, so this
is not an issue there.  However since I don't think selinux policy is allowed to
be per-arch this probably has to be changed everywhere.

(In F7 and later, the x86 emulator is used on all platforms.)

This is an selinux policy bug, not an X bug.  Adding to 5.2 radar and marking as
a potential blocker.
Comment 2 Daniel Walsh 2008-02-19 11:41:17 EST
Did you update to the latest U2 policy.  This should be in 

Fixed in /selinux-policy-2.4.6-121.el5

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