Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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))) |