Fedora Account System
Red Hat Associate
Red Hat Customer
I open this to track the mentioned bug also in bugzilla. I expect it is a `gdm`-related bug, but I file it for now against the only component whose relation I can prove. When a default installation of Fedora 43 Workstation or Fedora 43 Silverblue (VM KVM/QEMU, tested both in a Q35-UEFI and Q35-BIOS configuration) is adjusted with `sudo semanage login -m -s user_u -r s0 __default__`, then the next reboot leads to a coredump that breaks `gdm` before it is loaded: black screen with a "_" at the top left. Creating additionally a separate `unconfine_u` mapping for the user account `gdm` does not change the behavior. The issue does not occur on F43 KDE and F43 Kinoite when tested in the same configuration/VM-setting. Exact details and several tests, and also log files of two tests that reproduce the issue, are available at the forge of the case: https://forge.fedoraproject.org/atomic-desktops/tracker/issues/111 For reasons elaborated in later posts in the forge ticket, I originally thought this is Silverblue specific, which is why I originally filed it there. Direct links to "-k -r" and "-r" logs of a broken/affected boot: https://forge.fedoraproject.org/attachments/2869fd05-e4d3-4498-aa08-3c909499426e https://forge.fedoraproject.org/attachments/29b65a6f-1dc3-48cf-9776-4447ab340636 There is another log in the forge ticket, the content is widely the same. Reproducible: Always Steps to Reproduce: 1. Setup F43 Workstation or Silverblue, default installations, in a VM (either BIOS or EFI VM) 2. Finish installation all in a default way (so just click yourself through) 3. "sudo -s" or "sudo -i" 4. "sudo semanage login -m -s user_u -r s0 __default__" 5. "systemctl reboot" Actual Results: Coredump, gdm does not load. Expected Results: gdm loads and allows me to login Additional Information: All tests in KVM/QEMU, tested with Q35-UEFI and Q35-BIOS configurations. The VM is a CPU-passthrough of AMD Ryzen 6850U. The VM also had an additional Display added, a VNC one. I expect this to be not relevant though.
It's already implied in the forge ticket, but it might be worth highlighting that CentOS Stream 10 and Alma 10, each with GNOME in the same VM configuration, are not affected by this bug -> they work fine.
I just reproduced the issue with the official F44 images: `Fedora-Workstation-Live-44-1.7.x86_64.iso` (usual kvm/qemu vm, but with BIOS; default installation with default UNencrypted disk) `Fedora-Silverblue-ostree-x86_64-44-1.7.iso` (usual kvm/qemu vm, but with UEFI; default installation with default encrypted disk) In each case, I just clicked myself through the installation, everything default (except German keyboard:), and after the reboot, I set up the user account to finish the installation. Also, everything default. Then I shutdown and created a snapshot in the VM. If I boot again, it works fine. When I start and do `sudo -i` -> `semanage login -m -s user_u -r s0 __default__` and reboot again, the issue occurs: black screen only with the `_` at the top left. I can leave the screen that way for several minutes, no further change. If I force shutdown and start again, the issue is still there -> all works fine until the semanange cmd is done. When I reset the snapshot, it works again. The behavior about this is equal among F44 Workstation and F44 Silverblue. So it is still equal to F43. I am not sure if that belongs to `selinux-policy`, given the entries of the attached logs (see above), but I leave it to the maintainers to move this to another component or not...
I just did another test with F44 Workstation: Everything as before, but I mapped `__default__` to `staff_u` rather than `user_u` -> this works fine. I tested twice, and also changed then the mapping from `staff_u` to `user_u` again. Result 100% reproducible: staff_u works always fine, user_u always causes the coredump.
Now on F44, it is KDE (both KDE Spin and Kinoite) that seems incompatible with the setting: even the `staff_u` causes errors in sddm, but the login is not totally broke, it just has 4 error messages, but then the login works. I again used default installations of Fedora-Kinoite-ostree-x86_64-44-1.7.iso and Fedora-KDE-Desktop-Live-44-1.7.x86_64.iso ... and clicked myself through the default installations (one with BIOS and one with UEFI), then the usual setup of a "user", all by default. If I reboot, everything remains fine. If I then do `semanage login -m -s staff_u -r s0 __default__` and reboot, then the starting sddm shows three error message (see screenshot 1 that I submit after this post), and once I click away the three error message, sddm appears but with another error window (see screenshot 2 that I submit after this post). But then I can login. Testing with `user_u` in KDE Spin and Kinoite instead of `staff_u` leads now on F44 to the same result as on Silverblue & Workstation: sddm does not start at all -> Black screen. At least for the default installations as we ship them to our users, SELinux confinement mappings to __default__ are broke: user_u is broke on Silverblue and Workstation, and staff_u is broke on KDE Spin and Kinoite. Didn't test other variants.
Created attachment 2138932 [details] screenshot 1 for comment 4
Created attachment 2138933 [details] screenshot 2 for comment 4
Created attachment 2138964 [details] setsetroubleshoot journal of __default__=staff_u in KDE In KDE/sddm, there are least denials of setsetroubleshoot that offer some indication with __default__=staff_u, although I am not convinced this is the same issue as with __default__=user_u: log attached. But beyond the errors, I found out on KDE also sudo is broken for the staff_u users. So this log is from a default system that contains both __default__=staff_u and user=unconfined_u.
At least on KDE, the problem is the confinement on the account `plasmalogin`. This even solves the broken sddm with __default__=user_u. So both __default__=user_u and __default__=staff_u seem to work without annoying the user with black screens or error messages if I also do `semanage login -a -s unconfined_u plasmalogin` --- Concerning f44 gnome/gdm, I just found out that even if staff_u on __default__ seems to work as mentioned before, sudo is broken there too if the user is not unconfined. An UNconfinement on `gdm` like with `plasmalogin` does not solve the user_u issue on GNOME, but I still think this is a `gdm` bug as there is no related denial on GNOME variants while a denial should never cause a coredump anyway. --- In any case, I think we should stop to "support" user confinement as part of releases, as it leads to misleading assumptions of stability: in the course of this I found out that the last other user of the Confined Users SIG who has tested SELinux confinement has already given up on systems that have any GUI relation, and my assumption that confinement could be stable at least if the GUI accounts themselves are unconfined has proven not applicable too. Some applications break regularly, others are broken for years. My feeling is that at the moment it is just 2 people who test this each with their own, but not default, configurations.