Description of problem: Nvidia proprietary driver won't load with SELINUX enabled. I wasn't sure whether to file this under kernel or selinux-policy-targeted. No denials show up in audit.log. Version-Release number of selected component (if applicable): kernel 2.6.21-1.3194.fc7. FC7-RC2. Upgrade from FC6. How reproducible: Boot with SELINUX enabled Steps to Reproduce: 1. Boot with Nvidia proprietary driver and SELINUX enabled. 2. 3. Actual results: Boot message reports that can't stat /dev/nvidia0,1,23, and /dev/nvidiactl. From /var/log/messages: May 28 11:48:48 alcibiades kernel: audit(1180378096.858:4): avc: denied { create } for pid=454 comm="cp" name="nvidia0" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=chr_file May 28 11:48:48 alcibiades kernel: audit(1180378096.858:5): avc: denied { setattr } for pid=454 comm="cp" name="nvidia0" dev=tmpfs ino=1751 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=chr_file May 28 11:48:48 alcibiades kernel: nvidia: module license 'NVIDIA' taints kernel. Expected results: System should boot with Nvidia driver and SELINUX enabled. Additional info: With "enforcing=0" system boots normally with Nvidia driver.
This looks like you have a badly mislabeled file system or something is going very strange. Running the avc messages you attached gives output allow udev_t etc_t:chr_file { create setattr }; Whic indicates udev is trying to create a chr_file in an etc directory?
I ran ls -Z /dev/nvidia0: ls -Z /dev/nvidia0 crw------- joel root system_u:object_r:xserver_misc_device_t /dev/nvidia0 Running restorecon didn't change the label. The Nvidia driver was working without problems on FC6 running SELinux targeted. After the upgrade to FC7 RC 2, I built the nvidia.ko module from the Livna SRPM. /dev/nvidia0 has a date of 10 March, which is the date of xorg-x11-drv-nvidia-1.0.9755-2.lvn7. Do you have any suggestions? Relabeling the system?
I've also been getting this data from logwatch since the update from fc6: --------------------- Selinux Audit Begin ------------------------ *** Denials *** system_u system_u (chr_file): 15 times system_u system_u (dir): 85 times Number of audit daemon starts: 5 Number of audit daemon stops: 5 ---------------------- Selinux Audit End ------------------------- I don't remember ever seeing selinux audit entries in logwatch before.
See if setsebool -P allow_execstack=1 fixes your nvida problem.
Also please attach your audit.log
Created attachment 155713 [details] Audit Log
Your suggestion didn't work: [root@alcibiades audit]# setsebool -P allow_execstack=1 Could not change policy booleans
the nvidia driver needs a bunch of device files - /dev/nvidiactl and /dev/nvidia[0-9] chiefly. Something stashes them in /etc/udev/devices, where (in theory) udev copies them to /dev at startup. Perhaps this is udev trying to save these newly-created devices to /etc/udev/devices?
Joel setsebool failed? This seems like your machine is badly mislabeled. Have you triggered a relabel. touch /.autorelabel; reboot Will the idea of /etc/udev/devices is probably correct.
I did a relabel last night. It didn't help. ls - Z /etc/udev/devices crw------- root root system_u:object_r:etc_t nvidia0 crw------- root root system_u:object_r:etc_t nvidia1 crw------- root root system_u:object_r:etc_t nvidia2 crw------- root root system_u:object_r:etc_t nvidia3 crw------- root root system_u:object_r:etc_t nvidiactl They've been there all along. Their file dates are 10 March. I'll try removing the nvidia rpms, relabeling, and then reinstalling them.
I removed the nvidia rpms, relabeled, reinstalled. Same behavior, same messages.
The problem here is the labeling of the /etc/udev/devices directory. This directory should be labeled device_t and I bet it would work. You can create the directory chcon -t device_t /etc/udev/devices But why is udev creating the devices in this directory at all rather then on /dev?
Udev isn't creating these devices -- they're included in the livna rpm: [joel@alcibiades ~]$ rpm -ql xorg-x11-drv-nvidia-1.0.9755-2.lvn7 /dev/nvidia0 /dev/nvidia1 /dev/nvidia2 /dev/nvidia3 /dev/nvidiactl /etc/ld.so.conf.d/nvidia.conf /etc/modprobe.d/nvidia /etc/profile.d/nvidia.csh /etc/profile.d/nvidia.sh /etc/rc.d/init.d/nvidia /etc/udev/devices/nvidia0 /etc/udev/devices/nvidia1 /etc/udev/devices/nvidia2 /etc/udev/devices/nvidia3 /etc/udev/devices/nvidiactl -- snip remainder of file listing -- I'll try your suggestion and see if it works.
That didn't work either. Just after udev starts, I see the boot message: cp: cannot stat '/dev/nvidia0': permission denied. Then the same lines for the other devices. Then, I believe, cannot lstat /dev/nvidia0: no such file or directory. Once I've booted with enforcing=0, I can issue a setenforce 1 command and everything seems to work just fine.
/etc/udev/devices is deprecated anyway. The "clean" way now would be /etc/udev/makedev.d/60-nvidia.nodes and the nvidia rpm should also provide /etc/makedev.d/60nvidia.
I just filed this at livna where it belongs ( http://bugzilla.livna.org/show_bug.cgi?id=1504 )
(In reply to comment #16) > I just filed this at livna where it belongs ( > http://bugzilla.livna.org/show_bug.cgi?id=1504 ) Thanks for doing that. I tried to create a bugzilla account at Livna yesterday, but never got a confirmation email with a password. They may still be having problems related to their hard drive failure.
*** Bug 242102 has been marked as a duplicate of this bug. ***
*** Bug 242320 has been marked as a duplicate of this bug. ***
If you execute the following does everything work. # chcon -t bin_t /sbin/start_udev The startup script is labeled udev_exec_t and I believe this is incorrect. If we label it bin_t the startup will continue to run in initrc_t and will transition to udev_t only when udev starts up. If this does not work, we could also try to label /etc/udev/devices as device_t. chcon -R -t device_t /etc/udev/devices
Livna has issued a new rpm consistent with Harald Hoyer's comment and the problem now seems to be resolved, at least with respect to Livna.
*** Bug 242496 has been marked as a duplicate of this bug. ***