Bug 748069

proposing as NTH so we don't lose this one for final...

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.

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?

Does the device get created with the correct label on a reboot?

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.

(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

CCing the nvidia driver maintainer just in case.

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";

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

(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.

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

# 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

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

Harald why wouldn't udev realise these devices were created and fix the label?

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.

(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

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

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.

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

I would be willing to talk to them, but I have no idea how or who to contact.

(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 

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

Ok I sent him an email.

(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 };

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.

(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 ~]$

(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

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.

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.

(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 ~]$

I think Daniel meant 3.10.0-54.fc16, -53 was attempted to build before this fix was available.

Yes it looks like I jumped the gun.  Trying to build -53 again.

http://koji.fedoraproject.org/koji/buildinfo?buildID=271792

Build complete.

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 ~]$

Please update karma on libsepol


https://admin.fedoraproject.org/updates/FEDORA-2011-15209?_csrf_token=552ca8e9ae49a41c1c2169ff7ac6871d7924f704

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.

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.

*** Bug 732221 has been marked as a duplicate of this bug. ***

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

*** Bug 681924 has been marked as a duplicate of this bug. ***

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

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

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 =)

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.

*** Bug 751236 has been marked as a duplicate of this bug. ***

*** Bug 753055 has been marked as a duplicate of this bug. ***