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): kernel-2.6.18-78.el5.i686.rpm kernel-xen-2.6.18-78.el5.i686.rpm xorg-x11-drv-i810-1.6.5-9.6.0.3.el5.i386.rpm xorg-x11-server-Xnest-1.1.1-48.36.el5.i386.rpm xorg-x11-server-Xorg-1.1.1-48.36.el5.i386.rpm 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)
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.
Did you update to the latest U2 policy. This should be in Fixed in /selinux-policy-2.4.6-121.el5