F40 & SELinux confined users: the first Fedora KDE to be "productive" with enabled SELinux confined user (with restrictions)

Usually, I would not open a topic for that, but since we are a new kid on the block, and since this is (maybe) the first milestone we achieved: I thought its worth to exploit our new tags :classic_smiley:

Based upon my own classification (as someone who uses KDE with confined user accounts for over a year now), two of the four major issues with confined user accounts on Fedora KDE have been solved on F40: #1847 (at each login, it takes additional 30 seconds before the login screen disappears because of a timeout) and #1829 (logout, shutdown and reboot buttons do not work at all) are gone - although it is not yet clear if this was solved intentionally by our collaboration with the SELinux team ( @zpytela and his team), or if it was solved “accidentally” by adjustments in Plasma 6 (I keep you updated if I find out). So far, I cannot see a relation to the recently applied SELinux proposal [1] [2].

However, it also proves that I was wrong about the Bluetooth issues I elaborated in #1829: I assumed they have the same cause as the Button issue and thus would be solved automatically when the Button issue is solved. In fact, they are a separate issue because the Bluetooth issue remains after the Button issues have been solved. Further, video conferencing (at least browser-based) is not yet possible with confined user accounts at all (#2080): the browser is not allowed to access the camera.

Yet, at least when users only use bluetooth for their mouse and not for audio (and maybe other outputs), and if they do not need to access their camera in their browser (and maybe beyond), sysadm_u seems to do a good job now in Fedora KDE (I admit, that are still noteworthy restrictions). Of course even beyond the remaining issues, much more testing is necessary before we declare this stable or so.

It has to be noted that in the “good job” argument, I assume the issue #1917 is intended and thus nothing to be solved: most users will not experience it anyway, whereas users who modify their systems beyond the GUI are likely to be able to tackle it (at least if we spread a little documentation on how to “throw” user_home_dir_t profiles on applicable directories if and when appropriate). For most users this behavior might be even protective since they are maybe not aware of the security issues that go along when using directories outside ~ to store data while → SELinux would force them to make themselves aware.

Anyone who is interested in testing and elaborating how to solve the above and other remaining issues is welcome to do so. Any help & incentive is appreciated. Beyond the mentioned ones, there are further issues that need evaluation.

Further, my “good job” arguments are limited to using confined users of the sysadm_u profile and not more restrictive profiles, but this already introduces the majority of security measures to the user account and enables SELinux to restrict processes from accessing each other in a way comparable to containers (and thus mitigates one of the most vulnerable weaknesses of modern desktop environments), whereas “beyond user” means such as sudo/su, different-user-cockpit-web-logins or things such as * > /dev/*-like data forwarding beyond user ownership remain untouched. If you are a security-interested user and wanna check out what this is about, feel free to read this post and its solution, and maybe this post - and if you want, our wiki :classic_smiley:

In future, it might be worth to talk if we want to set the xdm_sysadm_login boolean by default to true in order to make it easier for users to exploit sysadm_u, although this change would have the (minor?) disadvantage to break with RHEL defaults. Maybe this is worth to be discussed for F42 or so.