I think it would definitely be worth getting this working. Contributions definitely welcome here, and perhaps @tdawson may be able to help with guidance and working with the relevant folks to fix up our SELinux policies on Fedora and RHEL.

Sounds good!

I was just curious and tested other live ISOs. The issue in Xfce is comparable, ~40 seconds until the first element of the desktop appears, ~1 minute until the desktop is fully therre, but the top bar remains "crippled" so that the buttons cannot be tested. But the initial symptoms are comparable to KDE (with a different desktop manager/lightdm, desktop env/xfce, backend/gtk+). Workstation with GNOME seems to work without the delay / idling. But in GNOME, it is not possible to open the file manager, which is denied (and it has frozen the first time I logged in with sysadm_u, but that might be not indicative).

So it seems we have a wider issue in Fedora with SELinux alignment. But we might learn/derive from CentOS, which seems to work fine when sysadm_u is enabled.

We might start here with KDE and first see if we can achieve and maintain "confining" permissions/roles. But if so, it could be interesting to check if there is interest to exchange in the management of SELinux alignment and testing among the Fedora variants.

I saw earlier that it can also reveal bugs (a previous Firefox build in stable crashed because of a bug: after copy-pasting with the middle-mouse-button, the next right-click led Firefox to try to access the origin, konsole, of the copy-paste again, which was denied so that it crashed at sysadm_u).

When I find some time, I will start to play with the permissions in KDE. However, any related information or documentation would be appreciated.

I've never worked with the selinux team. Things just always magically fixed themselves.
That being said, there is a new trend for packages, or groups of packages, to have their own selinux packages, such as flatpak-selinux.
But, I agree with you that we might have a wider problem.

Is this happening only on the live images? Does it still show up on installed images?
I can test, but if you already have, it would save time.

I have used the default live images to install Workstation (gnome) and the Xfce spin, but I conducted the actual tests on the installed Fedora, not on the live systems. In CentOS I used the default DVD ISO. In all cases, I did not update these installations, so they were at the update state of the finished installation of their respective image. In all cases, to ensure the issue is related to the confined users, I tested first normal, then with the confined user account, and then again without. In all cases I rebootet at least once and tested again.

Related commands (all semanage/setsebool commands need sudo/su) & conducted actions:

<install from default image>
<test case: login, open+use browser, open+use file manager, click a little around, shutdown with GUI buttons if possible>
semanage login -a -s sysadm_u username -> confine the user account that was setup during installation with sysadm_u
setsebool -P xdm_sysadm_login true -> unlike the other confined user accounts, sysadm_u is by default not allowed to login with x. This boolean allows sysadm_u users to login with x. -P = permanently (imho, at Fedora, we should change this boolean default, since our audience/use cases differ to RHEL)
<repeat test>
semanage login -m -s unconfined_u username -> remove the confinement and make it default again
<repeat test>
semanage login -m -s sysadm_u username -> confine it again
<reboot>
<repeat test>
<remove confinement>
<repeat test>

-> generally, to activate the semanage login ... it is necessary to logout and login again, a reboot shall be not necessary.

The elaboration of my first post with KDE is from my production system, where I use sysadm_u for several months (but I had no time so far to open the case here). I installed that system with F37 and upgraded it to F38 later, but I did modifications on the system.

So today, I also setup and tested a default KDE installation (installed using the default live image of F38) and updated it up to today + reboot before start testing. It behaves equal to my "production" Fedora KDE (see my initial post), with one minor difference:

Both KDE installations have an issue with the permissions of journal files, the error is in both cases the same but it occurs at different services:

In my production Fedora KDE (installed as F37, upgraded to F38, modified, up to date as of today):

[username@fedora ~]$ systemctl status --failed
× abrt-oops.service - ABRT kernel log watcher
     Loaded: loaded (/usr/lib/systemd/system/abrt-oops.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Fri 2023-05-26 15:06:55 CEST; 37min ago
   Duration: 1.120s
    Process: 2377 ExecStart=/usr/bin/abrt-dump-journal-oops -fxtD (code=exited, status=1/FAILURE)
   Main PID: 2377 (code=exited, status=1/FAILURE)
        CPU: 108ms

Warning: some journal files were not opened due to insufficient permissions.

In the default Fedora KDE (installed as F38, up to date as of today):

[username@localhost-live ~]$ systemctl status --failed
× mcelog.service - Machine Check Exception Logging Daemon
     Loaded: loaded (/usr/lib/systemd/system/mcelog.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Fri 2023-05-26 15:51:50 CEST; 57s ago
   Duration: 90ms
    Process: 719 ExecStart=/usr/sbin/mcelog --daemon --foreground (code=exited, status=1/FAILURE)
   Main PID: 719 (code=exited, status=1/FAILURE)
        CPU: 4ms

Warning: some journal files were not opened due to insufficient permissions.

In the default installation (the second; mcelog.service), I also tested with confined user (sysadm_u) and without (unconfined_u), including with another reboot: the issue is clearly related to the confinement.

Maybe the journal issue is related to the issue number 3) in my initial post.

Btw, since you referred to the container stuff, I use toolbox (for vlc from rpmfusion) without issues on sysadm_u (despite that it, just like other applications, causes avc denials from time to time, but they do not cause any issues). However, that it works does of course not prove the permissions to be set appropriately. I consider the avc denials in general positive so far since they imply that SELinux, just like with the Firefox issue, is not configured by policies and such to "just allow" anything in these processes. So I suggest to not focus on getting rid of all denials, but focus only on the least that is necessary that the system works stably (although denials are worth investigation and in some cases, are worth a bug report upstream).

I setup a VM with F38 KDE sysadm_u to test and play. When I find some time (not this week unfortunately), I will start testing which denials precisely cause the issues.

However, with the 30 second idling as example: since KDE in general works properly despite the related denial, I think we should consider to not get rid of the denial but to change KDE to avoid it, or simply to make KDE to not wait for the process/service that is impaired (at least if the idling is this denial's only effect). Adding permissions should be the last resort in solving issues imho.

Additionally, I identified another issue with sysadm_u (I assume video conferencing is a basic need of today) that might need changing permissions. On sysadm_u, the cameras/webcams cannot be used (I tested with Firefox, with+without sysadm_u). The origin is easy to identify:

May 29 01:40:42 fedora setroubleshoot[11007]: SELinux is preventing gst-plugin-scan from read access on the chr_file video0.

                                              *****  Plugin catchall (100. confidence) suggests   **************************

                                              If you believe that gst-plugin-scan should be allowed read access on the video0 chr_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 'gst-plugin-scan' --raw | audit2allow -M my-gstpluginscan
                                              # semodule -X 300 -i my-gstpluginscan.pp

May 29 01:40:42 fedora setroubleshoot[11007]: SELinux is preventing gst-plugin-scan from read access on the chr_file video0. For complete SELinux messages run: sealert -l 01a52f79-bc84-4d73-adaa-08e818959d2b

-> this occurrs for all devices that are /dev/video*

Normally, I would say these permissions could be just changed since any system of today needs to be able to do video conferencing, but I have not worked with the chr_file class before so I would check out the outreach of this permission in advance (... when I have some time : ). Feel free to let me know if someone has experience with that.

It may be worth discussing this on fedora-selinux itself: https://github.com/fedora-selinux/selinux-policy

That makes sense! I currently have to focus a kernel bug related to my hardware that makes it hard for me to work on my system, but once we could catch+fix this bug and once I could catch up with what remained undone till then, I will create a ticket there and start to check out how to improve the permissions/roles.

It may be worth discussing this on fedora-selinux itself: https://github.com/fedora-selinux/selinux-policy

I opened a ticket: https://github.com/fedora-selinux/selinux-policy/issues/1805

Hello,
I've just noticed this issue. I've used KDE with confined users for a few years, still don't have enough scenarios to test and add the needed rules to the policy. We can probably continue the discussion in the policy issue referred to above, just wanted to ensure you there are continuous improvements and will be.

Discourse topic to encourage people to contribute here: https://discussion.fedoraproject.org/t/security-enthusiasts-wanted-from-beginners-up-to-selinux-experts-to-make-up-the-selinux-confined-users-sig-to-foster-fedoras-security-capabilities/89127