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)))