Bug 1271401 - SELinux policy prevents the NVIDIA 358.xx driver from updating the screen
Summary: SELinux policy prevents the NVIDIA 358.xx driver from updating the screen
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 22
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-13 21:26 UTC by Daniel Dadap
Modified: 2023-09-14 03:06 UTC (History)
16 users (show)

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:
Clone Of:
Environment:
Last Closed: 2016-05-10 17:56:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Allow xdm_t to send datagrams to xserver_t (1.27 KB, patch)
2015-10-20 19:17 UTC, Aaron Plattner
no flags Details | Diff

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


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