Bug 748069 - selinux and nvidia means gdm fails to start
Summary: selinux and nvidia means gdm fails to start
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedNTH
: 681924 732221 751236 753055 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-21 21:59 UTC by Julian Sikorski
Modified: 2011-11-11 12:07 UTC (History)
18 users (show)

Fixed In Version: selinux-policy-3.10.0-55.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-10 17:29:56 UTC


Attachments (Terms of Use)

Description Julian Sikorski 2011-10-21 21:59:12 UTC
Description of problem:
I just upgraded to F16. Unfortunately, when selinux is in enforcing mode gdm will fail to start. /var/log/messages have the following denials inside:

Oct 21 23:47:27 snowball2 kernel: [ 1312.326589] type=1400 audit(1319233647.268:10): avc:  denied  { read write } for  pid=3260 comm="gnome-session-c" name="nvidiactl" dev=devtmpfs ino=23810 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 21 23:47:27 snowball2 kernel: [ 1312.326614] type=1400 audit(1319233647.268:11): avc:  denied  { open } for  pid=3260 comm="gnome-session-c" name="nvidiactl" dev=devtmpfs ino=23810 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 21 23:47:27 snowball2 kernel: [ 1312.326645] type=1400 audit(1319233647.268:12): avc:  denied  { ioctl } for  pid=3260 comm="gnome-session-c" path="/dev/nvidiactl" dev=devtmpfs ino=23810 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

Version-Release number of selected component (if applicable):
gdm-3.2.1.1-1.fc16.x86_64
selinux-policy-3.10.0-40.fc16.noarch
xorg-x11-drv-nvidia-285.05.09-1.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1. Try to start gdm on a machine with nvidia driver
2.
3.
  
Actual results:
gdm shows message: something went wrong, contact the administrator

Expected results:
gdm works

Additional info:

Comment 1 Adam Williamson 2011-10-21 22:06:28 UTC
proposing as NTH so we don't lose this one for final...

Comment 2 Miroslav Grepl 2011-10-23 20:29:06 UTC
I believe this won't be bug on F16. This should be created with the right label on F16 systems because of


dev_filetrans_all_named_dev()

which we have for random domains.


Julian,
could you execute

# restorecon -R -v /dev/nvidiactl

and then check if you see the same issue.

Comment 3 Julian Sikorski 2011-10-23 20:44:39 UTC
It helped, but not until I ran the same command on /dev/nvidia0. This makes me wonder: shouldn't such things be handled by anaconda? Or alternatively, shouldn't a full filesystem relabel be mandatory after upgrades?

Comment 4 Daniel Walsh 2011-10-24 13:08:14 UTC
Does the device get created with the correct label on a reboot?

Comment 5 Julian Sikorski 2011-10-24 13:27:10 UTC
I'll check when I get back home. As a side note, this is from the latest nvidia beta driver changelog:
Modified how the OpenGL driver allocates executable memory so it may continue to function properly if /tmp is mounted noexec. As some fallback allocation methods may be prohibited under SELinux policy, the driver now supports detection of this policy as well as manual override of this detection via the __GL_SELINUX_BOOLEANS environment variable.
I thought it might be interesting.

Comment 6 Julian Sikorski 2011-10-24 17:53:03 UTC
(In reply to comment #4)
> Does the device get created with the correct label on a reboot?

Well, it does not unfortunately. I rebooted and ran into the same problem:
$ sudo cat /var/log/messages | grep denied
-- snip --
Oct 24 19:44:15 snowball2 kernel: [   22.453578] type=1400 audit(1319478254.998:4): avc:  denied  { read write } for  pid=1444 comm="gnome-session-c" name="nvidiactl" dev=devtmpfs ino=21283 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 24 19:44:18 snowball2 kernel: [   25.747572] type=1400 audit(1319478258.296:5): avc:  denied  { read write } for  pid=1504 comm="gnome-shell" name="nvidiactl" dev=devtmpfs ino=21283 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 24 19:44:18 snowball2 kernel: [   25.774304] type=1400 audit(1319478258.323:6): avc:  denied  { read write } for  pid=1504 comm="gnome-shell" name="nvidiactl" dev=devtmpfs ino=21283 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 24 19:44:20 snowball2 kernel: [   28.034838] type=1400 audit(1319478260.586:7): avc:  denied  { read write } for  pid=1535 comm="gnome-shell" name="nvidiactl" dev=devtmpfs ino=21283 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 24 19:44:20 snowball2 kernel: [   28.088796] type=1400 audit(1319478260.640:8): avc:  denied  { read write } for  pid=1535 comm="gnome-shell" name="nvidiactl" dev=devtmpfs ino=21283 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

By the way, running the restorecon command gives the following output:
restorecon reset /dev/nvidiactl context system_u:object_r:device_t:s0->system_u:object_r:xserver_misc_device_t:s0
restorecon reset /dev/nvidia0 context system_u:object_r:device_t:s0->system_u:object_r:xserver_misc_device_t:s0

Comment 7 Julian Sikorski 2011-10-24 17:56:33 UTC
CCing the nvidia driver maintainer just in case.

Comment 8 Daniel Walsh 2011-10-24 18:06:26 UTC
Any idea who creates this device.  Currently we have the following transitions.

 sesearch -T | grep nvidiactl
type_transition kernel_t device_t : chr_file xserver_misc_device_t "nvidiactl"; 
type_transition initrc_t device_t : chr_file xserver_misc_device_t "nvidiactl"; 
type_transition init_t device_t : chr_file xserver_misc_device_t "nvidiactl"; 
type_transition livecd_t device_t : chr_file xserver_misc_device_t "nvidiactl"; 
type_transition sysadm_t device_t : chr_file xserver_misc_device_t "nvidiactl"; 
type_transition udev_t device_t : chr_file xserver_misc_device_t "nvidiactl"; 
type_transition unconfined_t device_t : chr_file xserver_misc_device_t "nvidiactl";

Comment 9 Julian Sikorski 2011-10-24 18:15:18 UTC
Hmm, interesting. This command results in a null output on my machine.
$ rpm -qa | grep selinux-policy
selinux-policy-targeted-3.10.0-46.fc16.noarch
selinux-policy-3.10.0-46.fc16.noarch

Comment 10 Nicolas Chauvet (kwizart) 2011-10-24 18:25:56 UTC
(In reply to comment #8)
> Any idea who creates this device.  Currently we have the following transitions.
There is a bugreport about this, but I don't know if it was reported upstream.
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1421#c7
Basically, the nvidia kernel module creates the device. The former is loaded by the Xorg driver.

Comment 11 Daniel Walsh 2011-10-24 18:45:25 UTC
Since this is a kernel module issue, the kernel must not be following SELinux rules when creating the device.

If you go and look at the device with ls after boot, is the device labeled correctly, IE udev should have noticed it and fixed the label

Comment 12 Julian Sikorski 2011-10-24 18:58:04 UTC
# ls -l /dev/nvidia*
crw-rw-rw-. 1 root root 195,   0 10-24 20:52 /dev/nvidia0
crw-rw-rw-. 1 root root 195, 255 10-24 20:52 /dev/nvidiactl

Comment 13 Daniel Walsh 2011-10-24 19:00:22 UTC
ls -lZ /dev/nvidia*

Comment 14 Julian Sikorski 2011-10-24 19:09:44 UTC
crw-rw-rw-. root root system_u:object_r:device_t:s0    /dev/nvidia0
crw-rw-rw-. root root system_u:object_r:device_t:s0    /dev/nvidiactl

Comment 15 Daniel Walsh 2011-10-24 19:26:39 UTC
Harald why wouldn't udev realise these devices were created and fix the label?

Comment 16 Adam Williamson 2011-10-28 19:31:04 UTC
Discussed at 2011-10-28 NTH review meeting. This does not appear to be new (the Fusion bug dates back to at least F15) and since it affects the NVIDIA proprietary driver it by definition does not affect Fedora release images, as they do not include this driver, and hence can certainly be safely fixed by an update, it doesn't need to go through freeze. RejectedNTH.

Comment 17 leigh scott 2011-10-29 08:28:03 UTC
(In reply to comment #16)

> they do not include this driver, and hence can certainly be safely fixed by an
> update, it doesn't need to go through freeze. RejectedNTH.

What are the chances that fedora will fix this issue?, in the past they haven't bothered.

https://bugzilla.redhat.com/show_bug.cgi?id=694918

Comment 18 Adam Williamson 2011-10-29 17:10:54 UTC
well, dan would only close it if he actually didn't think there was a bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 Daniel Walsh 2011-10-31 15:30:52 UTC
The problem is with the device driver from nvidia, but all the mechanisms we are using to try to compensate do not seem to be working.  From a fedora point of view, if enough people hit this error, I feel that we have to figure a good fix for it.

Comment 20 Julian Sikorski 2011-10-31 15:48:05 UTC
Well, did anyone from @redhat try to contact nvidia directly? I know it might be too much to ask for, but it also might be the case that they take an RH person more seriously than a random post at nvnews.net.
To reiterate, in the next driver version [1] an override for SELinux seems to be present, but this looks to me like sweeping the problem under the carpet rather than fixing it properly.
Nicolas, would you mind packaging 290.03 so that we could test if it helps?

[1] http://www.nvnews.net/vbulletin/showthread.php?p=2493300

Comment 21 Daniel Walsh 2011-10-31 15:58:25 UTC
I would be willing to talk to them, but I have no idea how or who to contact.

Comment 22 leigh scott 2011-10-31 16:51:38 UTC
(In reply to comment #21)
> I would be willing to talk to them, but I have no idea how or who to contact.

Try Aaron Plattner

aplattner@nvidia.com 

https://plus.google.com/118125769023950376556/about

Comment 23 Daniel Walsh 2011-10-31 18:12:11 UTC
Ok I sent him an email.

Comment 24 leigh scott 2011-11-01 17:55:57 UTC
(In reply to comment #19)
> From a fedora point
> of view, if enough people hit this error, I feel that we have to figure a good
> fix for it.


I'm can say with a degree of certainty that there will be a lot of people hit by this.
Perhaps a updated policy to allow the nvidia driver to function could be pushed to stable before the final release.


I'm using this for my nvidia guide for now.

su
wget http://leigh123linux.fedorapeople.org/pub/nvidia/selinux/nvidia.pp
semodule -i nvidia.pp



module nvidia 1.1;

require {
    type device_t;
    type xdm_t;
    class chr_file { read write ioctl open };
}

allow xdm_t device_t:chr_file { read write ioctl open };

Comment 25 Daniel Walsh 2011-11-01 18:57:31 UTC
Could someone try this policy



# cat > myxserver.te << _EOF

policy_module(myxserver, 1.1)

require {
    type xserver_t;
}

dev_filetrans_all_named_dev(xserver_t)

_EOF
# make -f /usr/share/selinux/devel/Makefile
# semodule -i myxserver.pp

Then reboot and see if the nvidia devices come up labeled correctly.

Comment 26 leigh scott 2011-11-01 20:00:58 UTC
(In reply to comment #25)
> Could someone try this policy
> 
> 
> 
> # cat > myxserver.te << _EOF
> 
> policy_module(myxserver, 1.1)
> 
> require {
>     type xserver_t;
> }
> 
> dev_filetrans_all_named_dev(xserver_t)
> 
> _EOF
> # make -f /usr/share/selinux/devel/Makefile
> # semodule -i myxserver.pp
> 
> Then reboot and see if the nvidia devices come up labeled correctly.

Your policy fixes the label here


before

[root@main-pc selinux.local]# ls -lZ /dev/nvidia*
crw-rw-rw-. root root system_u:object_r:device_t:s0    /dev/nvidia0
crw-rw-rw-. root root system_u:object_r:device_t:s0    /dev/nvidiactl
[root@main-pc selinux.local]# semodule -r nvidia
[root@main-pc selinux.local]# semodule -i myxserver.pp


after


[leigh@main-pc ~]$ ls -lZ /dev/nvidia*
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidia0
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidiactl
[leigh@main-pc ~]$

Comment 27 Julian Sikorski 2011-11-01 20:46:51 UTC
(In reply to comment #25)
> Could someone try this policy
> 
> 
> 
> # cat > myxserver.te << _EOF
> 
> policy_module(myxserver, 1.1)
> 
> require {
>     type xserver_t;
> }
> 
> dev_filetrans_all_named_dev(xserver_t)
> 
> _EOF
> # make -f /usr/share/selinux/devel/Makefile
> # semodule -i myxserver.pp
> 
> Then reboot and see if the nvidia devices come up labeled correctly.

I can confirm. With this policy:
$ ls -lZ /dev/nvidia*
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidia0
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidiactl

Comment 28 Eric Paris 2011-11-01 20:55:29 UTC
I'd like to thank (at least 2) NVIDIA employees (who I won't name because they probably don't want individual e-mail from random people) for working with us on this problem.  They are doing some, less than standard, things in their driver which we as the Fedora SELinux team didn't realize.  Once the right people from Red Hat got in touch with the right engineers at NVIDIA they were very helpful in explaining what they were doing on their end and help us find the best solution.  I know all of use are glad for the help and support on both ends of the conversation and I hope everyone's graphics cards will work correctly down the line!  I'm sure Dan will be pushing a policy with this change in the very near future publicly.

Comment 29 Daniel Walsh 2011-11-02 15:22:49 UTC
Ditto, 

Will be fixed in selinux-policy-3.10.0-52.fc16

But we also need you to update to the latest libsepol.

libsepol-2.1.3-2.fc16

Please try both out and update karma on the new libsepol.

Comment 30 leigh scott 2011-11-02 16:24:39 UTC
(In reply to comment #29)
> Ditto, 
> 
> Will be fixed in selinux-policy-3.10.0-52.fc16
> 
> But we also need you to update to the latest libsepol.
> 
> libsepol-2.1.3-2.fc16
> 
> Please try both out and update karma on the new libsepol.

selinux-policy-3.10.0-52.fc16 doesn't fix the issue here.


[leigh@main-pc ~]$ rpm -q selinux-policy libsepol
selinux-policy-3.10.0-52.fc16.noarch
libsepol-2.1.3-2.fc16.x86_64
[leigh@main-pc ~]$

Comment 31 Julian Sikorski 2011-11-02 17:32:47 UTC
I think Daniel meant 3.10.0-54.fc16, -53 was attempted to build before this fix was available.

Comment 32 Daniel Walsh 2011-11-02 20:04:06 UTC
Yes it looks like I jumped the gun.  Trying to build -53 again.

Comment 33 Daniel Walsh 2011-11-02 20:47:17 UTC
http://koji.fedoraproject.org/koji/buildinfo?buildID=271792

Build complete.

Comment 34 leigh scott 2011-11-02 20:50:21 UTC
It works here.

[leigh@main-pc ~]$ rpm -q selinux-policy libsepol
selinux-policy-3.10.0-53.fc16.noarch
libsepol-2.1.3-2.fc16.x86_64
[leigh@main-pc ~]$ ls -lZ /dev/nvidia*
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidia0
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidiactl
[leigh@main-pc ~]$

Comment 36 Julian Sikorski 2011-11-02 21:09:39 UTC
Confirmed on my machine too:
$ ls -lZ /dev/nvidia*
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidia0
crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidiactl

I did run semodule -r myxserver prior to updating btw.

Comment 37 Sandro Mathys 2011-11-03 09:44:32 UTC
During upgrade, I've seen some errors:

Running Transaction
  Updating   : libsepol-2.1.3-2.fc16.x86_64                                   1/8 
  Updating   : selinux-policy-3.10.0-53.fc16.noarch                           2/8 
  Updating   : selinux-policy-targeted-3.10.0-53.fc16.noarch                  3/8 
libsemanage.semanage_install_active: setfiles returned error code 1.
/usr/sbin/semodule:  Failed!
  Updating   : libsepol-devel-2.1.3-2.fc16.x86_64                             4/8 
  Cleanup    : selinux-policy-targeted-3.10.0-46.fc16.noarch                  5/8 
  Cleanup    : libsepol-devel-2.1.1-1.fc16.x86_64                             6/8 
  Cleanup    : selinux-policy-3.10.0-46.fc16.noarch                           7/8 
  Cleanup    : libsepol-2.1.1-1.fc16.x86_64                                   8/8 

Will reboot shortly and see if they are reason to worry or only just a polishing issue.

Comment 38 Eric Paris 2011-11-07 22:58:57 UTC
*** Bug 732221 has been marked as a duplicate of this bug. ***

Comment 39 Vladimir Shebordaev 2011-11-08 04:09:49 UTC
I should confirm that as of selinux-policy-3.10.0-55.fc16.noarch it works.

ted#pts/0[6232]~>rpm -q selinux-policy xorg-x11-drv-nvidia
selinux-policy-3.10.0-55.fc16.noarch
xorg-x11-drv-nvidia-285.05.09-1.fc16.i686

Comment 40 Eric Paris 2011-11-08 13:21:54 UTC
*** Bug 681924 has been marked as a duplicate of this bug. ***

Comment 41 Nicolas Chauvet (kwizart) 2011-11-08 13:32:05 UTC
Can someone submit a bodhi update of selinux-policy later than -53 ?
The latest bodhi update is selinux-policy-3.10.0-51.fc16 (stable)
Thx

Comment 42 Fedora Update System 2011-11-08 14:05:29 UTC
selinux-policy-3.10.0-55.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-55.fc16

Comment 43 Andre Costa 2011-11-09 21:52:09 UTC
libsepol-2.1.3-2
selinux-policy-targeted-3.10.0-53
selinux-policy-3.10.0-53

fixed the problem for me (karma already updated for all of them).

Kudos for coordinating with nVidia to work this out, I'm glad you guys sorted it out together (comment #28). Everybody wins when this happens =)

Comment 44 Fedora Update System 2011-11-10 17:29:56 UTC
selinux-policy-3.10.0-55.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 45 Andre Robatino 2011-11-11 12:06:18 UTC
*** Bug 751236 has been marked as a duplicate of this bug. ***

Comment 46 Andre Robatino 2011-11-11 12:07:26 UTC
*** Bug 753055 has been marked as a duplicate of this bug. ***


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