Bug 1944694
Summary: | SELinux is preventing gdm from 'getattr' accesses on the file /run/gdm/custom.conf. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Larsen <plarsen> |
Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 34 | CC: | alex.ploumistos, chrissharp123, decathorpe, dwalsh, grepl.miroslav, hartsjc, lvrabec, mmalik, omosnace, plautrba, roshan.shariff, vmojzis, zpytela |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:5761140d5833174e8cade9ceff710fbcae0a41da99a7c7ada4d237575a86a1d6;VARIANT_ID=workstation; | ||
Fixed In Version: | selinux-policy-34.5-1.fc34 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-05-07 01:02:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Larsen
2021-03-30 13:56:39 UTC
Hi, It looks like the file in the setroubleshoot report has incorrect label. Along with the restorecon plugin suggestion, you can fix the label with a single command: # /sbin/restorecon -v /run/gdm/custom.conf It will not help you after the reboot though. The directory content should look as follows: vm-f34# ls -laZ /run/gdm total 4 drwx--x--x. 3 root gdm system_u:object_r:xdm_var_run_t:s0 80 Mar 29 13:36 . drwxr-xr-x. 37 root root system_u:object_r:var_run_t:s0 880 Mar 29 13:36 .. -rw-r--r--. 1 root root system_u:object_r:xdm_var_run_t:s0 4 Mar 29 13:36 gdm.pid drwx------. 2 gdm gdm system_u:object_r:xdm_var_run_t:s0 40 Mar 29 13:36 greeter Do you know which service created the custom.conf file and how? Any newly created file should inherit the directory type. (In reply to Zdenek Pytela from comment #1) > Hi, > > It looks like the file in the setroubleshoot report has incorrect label. > Along with the restorecon plugin suggestion, you can fix the label with a > single command: > > # /sbin/restorecon -v /run/gdm/custom.conf > > It will not help you after the reboot though. The directory content should > look as follows: > > vm-f34# ls -laZ /run/gdm > total 4 > drwx--x--x. 3 root gdm system_u:object_r:xdm_var_run_t:s0 80 Mar 29 13:36 > . > drwxr-xr-x. 37 root root system_u:object_r:var_run_t:s0 880 Mar 29 13:36 > .. > -rw-r--r--. 1 root root system_u:object_r:xdm_var_run_t:s0 4 Mar 29 13:36 > gdm.pid > drwx------. 2 gdm gdm system_u:object_r:xdm_var_run_t:s0 40 Mar 29 13:36 > greeter > > Do you know which service created the custom.conf file and how? Any newly > created file should inherit the directory type. I show have noted that the restorecon "works" if you do it every time you login or GDM restarts. Still a bug :D The create session creates it. It's content: [daemon] WaylandEnable=false My /etc/gdm/custom.conf looks like: [daemon] # Uncoment the line below to force the login screen to use Xorg WaylandEnable=false (the rest are commented out or empty). According to https://wiki.gentoo.org/wiki/GNOME/GDM it says that /usr/libexec/gdm-disable-wayland is what generates this "temporary" file. On my f34 vm, the udev rule executes /usr/libexec/gdm-runtime-config. Anyway, if the temporary file was created a common way, it would inherit the directory type, that is xdm_var_run_t. Are you aware of customizations made on your system? (In reply to Zdenek Pytela from comment #3) > On my f34 vm, the udev rule executes /usr/libexec/gdm-runtime-config. > Anyway, if the temporary file was created a common way, it would inherit the > directory type, that is xdm_var_run_t. > > Are you aware of customizations made on your system? Sure - some of them are old but I can enumerate them. I just need to know what you're looking for. Note the waylandEnable=false is a custom setting. Here what that file and it's parent directory has: [root@boss libexec]# ls -Zd /usr/libexec/gdm-runtime-config /usr/libexec system_u:object_r:bin_t:s0 /usr/libexec system_u:object_r:bin_t:s0 /usr/libexec/gdm-runtime-config The /run/gdm/custom.conf: # ls /run/gdm -lZ total 8 -rw-r--r--. 1 root root system_u:object_r:var_run_t:s0 29 Mar 31 19:06 custom.conf So they don't match? Peter, Does this commit description match your case? https://github.com/fedora-selinux/selinux-policy/pull/650/commits/09ba7079ba74136d80a4f331fbcf737172cbfb32 It should address your problem, too. (In reply to Zdenek Pytela from comment #5) > Peter, > > Does this commit description match your case? > https://github.com/fedora-selinux/selinux-policy/pull/650/commits/ > 09ba7079ba74136d80a4f331fbcf737172cbfb32 > > It should address your problem, too. I'm really not sure how to address the link - not seeing a solution there or perhaps not understanding how to implement the solution. Here's the content of /usr/lib/udev/rules.d/61-gdm.rules: # cat 61-gdm.rules # disable Wayland on Hi1710 chipsets ATTR{vendor}=="0x19e5", ATTR{device}=="0x1711", RUN+="/usr/libexec/gdm-runtime-config set daemon WaylandEnable false" # disable Wayland when using the proprietary nvidia driver DRIVER=="nvidia", RUN+="/usr/libexec/gdm-runtime-config set daemon WaylandEnable false" # disable Wayland if modesetting is disabled IMPORT{cmdline}="nomodeset", RUN+="/usr/libexec/gdm-runtime-config set daemon WaylandEnable false" This seems to be a selinux policy issue more than a udev issue, so the link confuses me. In my situation, wayland is explicitly turned off and I do run the akmod-nvidia to support my nvidia card so these udev rules are definitely fired and explains how the file is created. Similar problem has been detected: This AVC denial happens at every boot. gdm on Xorg; Fedora Workstation 34 upgraded from 33, if that matters. setroubleshoot tells me to fix the label to be xdm_var_run_t, but even if I do "restorecon" on that file. Butt looks like the file still gets created with the wrong label at every boot. (Even a full system relabel after the upgrade from Workstation 33 to 34 did not help.) hashmarkername: setroubleshoot kernel: 5.11.13-300.fc34.x86_64 package: selinux-policy-targeted-34.3-1.fc34.noarch reason: SELinux is preventing gdm from 'getattr' accesses on the file /run/gdm/custom.conf. type: libreport Until the context is restored, users get a notification about a denial every time they unlock their screens, so they're bound to notice. (In reply to Peter Larsen from comment #6) > (In reply to Zdenek Pytela from comment #5) > > Peter, > > > > Does this commit description match your case? > > https://github.com/fedora-selinux/selinux-policy/pull/650/commits/ > > 09ba7079ba74136d80a4f331fbcf737172cbfb32 > > > > It should address your problem, too. > > I'm really not sure how to address the link - not seeing a solution there or > perhaps not understanding how to implement the solution. Peter, Sorry for misunderstanding, I only wanted you to compare the commit description with your state. To me, it seems to be the same, the transition for udev creating the /run/gdm directory is needed in the policy, so I'll adjust the commit and put into the next build. *** Bug 1954086 has been marked as a duplicate of this bug. *** I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/706 FEDORA-2021-b9564e597a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9564e597a FEDORA-2021-b9564e597a has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b9564e597a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9564e597a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-b9564e597a has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. # rpm -q selinux-policy selinux-policy-34.5-1.fc34.noarch Raw Audit Messages type=AVC msg=audit(1620420567.189:408): avc: denied { write } for pid=2579 comm="gsd-keyboard" name="dbus-c7TSGlkAkz" dev="tmpfs" ino=53 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file permissive=0 # /usr/libexec/selinux/hll/pp my-gnomesessionc.pp (typeattributeset cil_gen_require xdm_t) (typeattributeset cil_gen_require tmp_t) (allow xdm_t tmp_t (sock_file (write))) Had to expand to following to prevent gnome-session AVCs (typeattributeset cil_gen_require tmp_t) (typeattributeset cil_gen_require xdm_t) (typeattributeset cil_gen_require unconfined_service_t) (allow xdm_t tmp_t (sock_file (write))) (allow xdm_t unconfined_service_t (unix_stream_socket (connectto))) |