Description of problem: /run/gdm/custom.conf has the wrong selinux context - this happens after reboot and when gdm restarts. SELinux is preventing gdm from 'getattr' accesses on the file /run/gdm/custom.conf. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /run/gdm/custom.conf default label should be xdm_var_run_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /run/gdm/custom.conf ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that gdm should be allowed getattr access on the custom.conf file 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: # ausearch -c 'gdm' --raw | audit2allow -M my-gdm # semodule -X 300 -i my-gdm.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_run_t:s0 Target Objects /run/gdm/custom.conf [ file ] Source gdm Source Path gdm Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.7-28.fc34.noarch Local Policy RPM selinux-policy-targeted-3.14.7-28.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 5.11.10-300.fc34.x86_64 #1 SMP Thu Mar 25 14:03:32 UTC 2021 x86_64 x86_64 Alert Count 238 First Seen 2021-03-03 21:14:05 EST Last Seen 2021-03-30 09:53:33 EDT Local ID d709095f-baa2-43a8-b75e-9fd106539c8c Raw Audit Messages type=AVC msg=audit(1617112413.731:603): avc: denied { getattr } for pid=2298 comm="gdm-x-session" path="/run/gdm/custom.conf" dev="tmpfs" ino=1788 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=1 Hash: gdm,xdm_t,var_run_t,file,getattr Version-Release number of selected component: selinux-policy-targeted-3.14.7-28.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.14.0 hashmarkername: setroubleshoot kernel: 5.11.10-300.fc34.x86_64 type: libreport
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)))