Bug 1271401

Summary: SELinux policy prevents the NVIDIA 358.xx driver from updating the screen
Product: [Fedora] Fedora Reporter: Daniel Dadap <ddadap>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 22CC: abc.mikey, abuse, aplattner, ddadap, devin, dominick.grift, dwalsh, laurent.rineau__fedora, lvrabec, mgrepl, mike, mtessun, negativo17, plautrba, roshan.shariff, sjenning
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: selinux-policy-3.13.1-128.26.fc22 selinux-policy-3.13.1-128.28.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-10 17:56:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Allow xdm_t to send datagrams to xserver_t none

Description Daniel Dadap 2015-10-13 21:26:33 UTC 
Description of problem:

The NVIDIA proprietary driver was recently updated to use Unix SOCK_DGRAM sockets. This seems to be tripping up on Fedora's SELinux policy, with the end result of preventing X clients such as GDM from updating the screen, as reported at:

https://devtalk.nvidia.com/default/topic/884783/linux/358-beta-not-working-properly-in-fedora-22

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


How reproducible: Start GDM with SELinux enabled and in enforcing mode, using the latest NVIDIA 358.09 beta driver.


Steps to Reproduce:
1. Install the NVIDIA driver, version 358.09 or later: http://www.nvidia.com/Download/driverResults.aspx/92712/en-us
2. Start GDM

Actual results: GDM displays a blank grey screen. VT switching away from X and back will allow the screen to update.


Expected results: GDM should update the display interactively.


Additional info:

Setting SELinux to permissive mode avoids the problem. I am not an SELinux expert, and am not sure as to the best way to update the policy to allow this. It's possible that other X clients may be affected as well, but FWIW, starting gnome-shell manually in a bare X server seems to avoid this issue. The following messages were recorded in the system log:

Oct 13 09:53:01 localhost.localdomain audit[4790]: <audit-1400> avc: denied { sendto } for pid=4790 comm="gnome-shell" path=006E7669646961336130316261643400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0
Oct 13 09:53:01 localhost.localdomain audit[4790]: <audit-1400> avc: denied { sendto } for pid=4790 comm="gnome-shell" path=006E7669646961336130316261643400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0
Oct 13 09:53:01 localhost.localdomain dbus[835]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Oct 13 09:53:02 localhost.localdomain dbus[835]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Oct 13 09:53:02 localhost.localdomain setroubleshoot[4954]: SELinux is preventing gnome-shell from sendto access on the unix_dgram_socket @nvidia3a01bad4. For complete SELinux messages. run sealert -l 0b219b78-fcbf-489d-aef9-77040464a94a
Oct 13 09:53:02 localhost.localdomain python[4954]: SELinux is preventing gnome-shell from sendto access on the unix_dgram_socket @nvidia3a01bad4.

                                                   ***** Plugin catchall (100. confidence) suggests  **************************

                                                   If you believe that gnome-shell should be allowed sendto access on the @nvidia3a01bad4 unix_dgram_socket by default.
                                                   Then you should report this as a bug.
                                                   You can generate a local policy module to allow this access.
                                                   Do
                                                   allow this access for now by executing:
                                                   # grep gnome-shell /var/log/audit/audit.log | audit2allow -M mypol
                                                   # semodule -i mypol.pp

Oct 13 09:53:06 localhost.localdomain audit[1]: <audit-1131> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=geoclue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 13 09:53:06 localhost.localdomain setroubleshoot[4954]: SELinux is preventing gnome-shell from sendto access on the unix_dgram_socket @nvidia3a01bad4. For complete SELinux messages. run sealert -l 0b219b78-fcbf-489d-aef9-77040464a94a
Oct 13 09:53:06 localhost.localdomain python[4954]: SELinux is preventing gnome-shell from sendto access on the unix_dgram_socket @nvidia3a01bad4.

                                                   ***** Plugin catchall (100. confidence) suggests  **************************

                                                   If you believe that gnome-shell should be allowed sendto access on the @nvidia3a01bad4 unix_dgram_socket by default.
                                                   Then you should report this as a bug.
                                                   You can generate a local policy module to allow this access.
                                                   Do
                                                   allow this access for now by executing:
                                                   # grep gnome-shell /var/log/audit/audit.log | audit2allow -M mypol
                                                   # semodule -i mypol.pp
Comment 1 Aaron Plattner 2015-10-20 19:17:06 UTC 
Created attachment 1084892 [details]
Allow xdm_t to send datagrams to xserver_t

I did a little investigation and it looks like normal applications can send datagrams just fine.  The reason this fails here is because gnome-shell inherits the xdm_t context from gdm, and that's more restricted.  There's a rule in xserver.te that explicitly allows xdm_t to connect to the X server's UNIX stream sockets, so I think this patch should do the trick.  I haven't been able to figure out how to compile these policy rules, so I haven't been able to verify it.
Comment 2 Miroslav Grepl 2015-11-10 09:10:06 UTC 
It makes sense. 

Did you test a local policy?
Comment 3 Seth Jennings 2015-11-20 22:37:51 UTC 
I am seeing this as well (gdm login hangs until I switch vterms with alt-f2).

However, I don't think this is (only) an selinux issue.  I set selinux enforcement to permissive in /etc/selinux/config and it is still an issue.

I need to look into this more.
Comment 4 Michael Cronenworth 2015-11-20 22:42:50 UTC 
@Miroslav,
Aaron is on extended vacation so I doubt we'll see further replies from him for several weeks.

@Seth,
The new NVIDIA 358.16 driver released today implements a fallback to workaround this policy issue.
Comment 5 Seth Jennings 2015-11-20 23:28:35 UTC 
(In reply to Michael Cronenworth from comment #4)
> @Seth,
> The new NVIDIA 358.16 driver released today implements a fallback to
> workaround this policy issue.

I just updated and I'm still seeing the issue, which is really two issues:
1) the selinux denial and (goes away in permissive mode)
2) the gdm login hang (happens even in permissive mode)

Driver version:
NVRM: loading NVIDIA UNIX x86_64 Kernel Module  358.16  Mon Nov 16 19:25:55 PST 2015

sealert:
=========================================
SELinux is preventing gnome-shell from sendto access on the unix_dgram_socket 006E7669646961333336386366313200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that gnome-shell should be allowed sendto access on the 006E7669646961333336386366313200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 unix_dgram_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep gnome-shell /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:system_r:xserver_t:s0-s0:c0.c1023
Target Objects                006E7669646961333336386366313200000000000000000000
                              00000000000000000000000000000000000000000000000000
                              0000000000000000000000000000 [ unix_dgram_socket ]
Source                        gnome-shell
Source Path                   gnome-shell
Port                          <Unknown>
Host                          
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-154.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     
Platform                      Linux 
                              4.2.6-300.fc23.x86_64 #1 SMP Tue Nov 10 19:32:21
                              UTC 2015 x86_64 x86_64
Alert Count                   1
First Seen                    2015-11-20 17:07:40 CST
Last Seen                     2015-11-20 17:07:40 CST
Local ID                      2893aa41-e4de-4d9f-90fc-332b9f54d358

Raw Audit Messages
type=AVC msg=audit(1448060860.607:527): avc:  denied  { sendto } for  pid=1642 comm="gnome-shell" path=006E7669646961333336386366313200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0


Hash: gnome-shell,xdm_t,xserver_t,unix_dgram_socket,sendto
=========================================

For the second issue, the login process seems to be hanging in gdm-session-worker, blocking the start of gdm-x-session.
Comment 6 Michael Cronenworth 2015-11-21 18:16:08 UTC 
I no longer see GDM hang with the latest driver so I don't know what to tell you. I'm always in Enforcing mode and no alerts were thrown.
Comment 7 Martin Tessun 2015-11-22 11:17:17 UTC 
Most probably this is due to:

[Quote]
Added a fallback to allow GLX to function when UNIX domain socket communication is blocked between NVIDIA client-side GLX and NVIDIA server-side GLX. For example, the default SELinux policy on Fedora 22 prevents the NVIDIA 358.09 GLX driver from working in GDM3:

https://bugzilla.redhat.com/show_bug.cgi?id=1271401
[/Quote]

from Nvidias latest driver (358.16): http://www.nvidia.com/download/driverResults.aspx/95921/en-us

As such this seems to be fixed; still I think the SELinux policy needs to be adjusted accordingly.
Comment 8 mikey 2016-01-09 10:41:05 UTC 
I'm still seeing the following on Fedora 23 even with the NVidia drivers 358.16.

SELinux is preventing gnome-shell from sendto access on the unix_dgram_socket 006E7669646961396432666264376500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that gnome-shell should be allowed sendto access on the 006E7669646961396432666264376500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 unix_dgram_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep gnome-shell /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:system_r:xserver_t:s0-s0:c0.c1023
Target Objects                006E7669646961396432666264376500000000000000000000
                              00000000000000000000000000000000000000000000000000
                              0000000000000000000000000000 [ unix_dgram_socket ]
Source                        gnome-shell
Source Path                   gnome-shell
Port                          <Unknown>
Host                          XXXX
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-158.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     XXXXX
Platform                      Linux XXXXX 4.2.8-300.fc23.x86_64 #1 SMP Tue Dec
                              15 16:49:06 UTC 2015 x86_64 x86_64
Alert Count                   82
First Seen                    2015-11-28 18:42:13 GMT
Last Seen                     2016-01-09 10:37:20 GMT
Local ID                      ddcf4e45-6021-47dc-967e-5443d450b4fb

Raw Audit Messages
type=AVC msg=audit(1452335840.911:529): avc:  denied  { sendto } for  pid=1367 comm="gnome-shell" path=006E7669646961396432666264376500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0


Hash: gnome-shell,xdm_t,xserver_t,unix_dgram_socket,sendto
Comment 9 Lukas Vrabec 2016-01-21 16:55:58 UTC 
commit 93adad2760f066b8cccc2fa9dbfeaa9ec6442966
Author: Lukas Vrabec <lvrabec>
Date:   Thu Jan 21 17:51:56 2016 +0100

    Allow xdm send gram sockets to xserver. BZ(1271401)
Comment 10 Simone Caronni 2016-01-22 08:32:05 UTC 
Where is such version? The commit is not even in git:

http://pkgs.fedoraproject.org/cgit/rpms/selinux-policy.git/
https://git.fedorahosted.org/git/selinux-policy.git

I thought all Fedora (owned) packages were in one of those two repositories. Am I wrong?
Comment 11 Fedora Update System 2016-02-15 17:46:10 UTC 
selinux-policy-3.13.1-128.27.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab
Comment 12 Fedora Update System 2016-02-17 06:25:40 UTC 
selinux-policy-3.13.1-128.27.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab
Comment 13 Fedora Update System 2016-02-18 12:26:41 UTC 
selinux-policy-3.13.1-128.28.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab
Comment 14 Fedora Update System 2016-02-21 18:28:39 UTC 
selinux-policy-3.13.1-128.28.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab
Comment 15 Fedora Update System 2016-05-10 17:55:24 UTC 
selinux-policy-3.13.1-128.28.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 16 Red Hat Bugzilla 2023-09-14 03:06:41 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days