Problems when using SELinux confined user accounts with staff_u on Fedora

I just recently installed Fedora 39 Workstation, setup an alternate user account, and decided to play around with staff_u. It was brutal.

Off the top of my head, I could not get gnome-boxes to open, nautilus wouldn’t open, I couldn’t open journalctl with sudo (and yes, I followed the Fedora docs instructions setting up sudo… unless I interpreted something incorrectly), couldn’t get my VPN client to run, and so on. I can’t even imagine trying to use user_u. I eventually (just as an experiment) decided to create an “all” module comprised by the use of audit2allow and things mostly worked better, though I surmise that largely defeats the purpose. I disabled that module to try and focus on building modules for critical things hoping to eventually get to a usable state, but haven’t made much progress as life has been busy recently.

I have a Fedora KDE install that runs the typical unconfined_u as my main for now with the Workstation/Gnome install on a separate SSD. Incidentally I tried doing staff_u on my Fedora KDE install as well, and I couldn’t even get KDE to load to desktop (took btrfs snapshots before just in case :slight_smile: ). Any progress or suggestions on this? I have a basic understanding of Linux users being mapped to SELinux users, role translation, and type enforcement so I might be able to contribute from the “competent SELinux noob” position.


Hi Jay,

welcome back to the Forum :slight_smile:

In short, I think sysadm_u is the confinement that is most interesting for most Fedora use cases (but you have to enable a boolean in advance: setsebool -P xdm_sysadm_login on → this allows sysadm_u to use the GUI). Be aware that sysadm_u does not add any privileges but only restricts some compared to unconfined_u. But it introduces the majority (and the most important) advantages and security measures of confined users while keeping possibilities used by many Fedora users available.

There is a recent topic that might answer some of the underlying questions of your issue: How to enable SELinux user confinement? What to consider? (only the first two posts are interesting). With regards to that …

I don’t know how gnome-boxes itself is constructed since I don’t use it, but this likely relates to the case of cockpit I mentioned in the recent topic. Be aware that staff_u is intended to minimize capabilities of a user and restrict it fully into its own space. Using virtual machines has many outreaches and often does not work when fully restricted. This is explicitly intended. So within the staff_u account, you can only use virtualization applications that do not by default establish connections/outreaches for administration. This includes cockpit, but even cockpit can only be used with the credentials of the user that is logged in (so if you start cockpit in the browser of the staff_u user “Jay”, then you can only log into cockpit with the user credentials of “Jay”). And the administration possibilities will be restricted, too.

Because staff_u is more desgined for corporate realms, where any user shall have limited access (which includes attached USB devices that are not explicitly profiled for the user), I think sysadm_u should be the goal for Fedora for now. The approach I currently have in mind is to combine sysadm_u on one hand, and use other means from the Confined Users SIG (those proposed by siosm) to then mitigate+disable su & sudo at all when/where applicable. This is why we consolidated the two areas. It will be then up to the users if they want both or only one of the two measures.

What could be interesting for you. although I am not sure if it will be a “sufficient experience” for you, is to combine the staff_u user account with the sysadm_r role (“r” at the end, not “u”): - problem: this is not designed for use in graphical environments, and thus might cause issues when used to run graphical applications through, e.g., sudo <app>. But feel free to make a more sophisticated test and let us know if that feels an acceptable solution for you.

With regards to the issues you focus on, I assume user_u would be widely the same, except that even sudo would be blocked (imho, in the use cases relevant for Fedora, I assume that beyond sudo, user_u and staff_u are much alike with only minor differences). But I agree that user_u is unlikely to be useful for you, too :wink:

I have not yet tested it explicitly, but I think you need to implement the sudo with the sysadm_r role as mentioned above to achieve that. Keep in mind: staff_u shall also offer mitigation when an account is captured or abused, and it is explicitly intended to limit the user from outreaching to other users or beyond (which would be the case with the root journalctl). If you want to remain with staff_u, I suggest to use sysadm_r for that (and for the worst case, keep the root account with unconfined_u and different credentials active).

I saw that before in my initial “screening” of the different spins. That seems indeed like a bug in the profiles that still exists.

If you are interested, feel free to open a topic in the Project Discussion category with the security-sig and the confined-users tag, provide elaboration of the issue (what occurs under which circumstances, and the exact details of the Fedora you use, e.g., Fedora Workstation 40, no third party repos, up to date as of now), provide two types of outputs and let us know the exact time when you provoked the SELinux denial. Here the two outputs:

ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
journalctl --no-hostname --boot=0

Feel free to further anonymize the output. Also, it would be ok to limit the output of the journalctl command to an extract of the time of the very issue plus 30 seconds before and 30 seconds after. However, if you provide only such an extract, please add additionally the output of uname -r.

The same as above: Feel free to open a topic in Project Discussion. I cannot reproduce this to be honest. I was using staff_u on KDE some time, and although there are open issues (while some are intended and make staff_u unattractive for many use cases), I have never had that issue. However, I have not yet tried staff_u on F40. Could you share the exact details of your Fedora that has this issue? E.g., F40, KDE Spin, no third party repos, up to date as of now, etc. ?

We are happy to help, and to get your incentives. It is data we can use to improve SELinux. You already shared some data we have not had before. Our SIG is to enable this type of collaboration and bring all stakeholder groups together in order to facilitate a “joint evolvement of members in their knowledge”. Welcome to the SIG :stuck_out_tongue:

1 Like

Added selinux

Slight addition, you can also increase security by disabling the *_exec_content booleans. This works fine on my Fedora KDE, and it sometimes can even reveal if applications we use are implemented using bad practices. The related booleans are


Again, you can play if that fits your needs. Leaving these booleans the default way is not a security issue on itself. This is more about preventive vulnerability mitigation when applications or so are malicious or behave unintended (e.g., interesting for people using third party repos that are not fully trusted but whose use cannot be avoided). Any condition here is much more secure than most systems out there.

Personally, I have no issues with having all disabled.

When it comes to virtualization, I use virt-manager and cockpit from a sysadm_u account, but I log into cockpit using a user_u account, which works fine.

I only use virt-manager from my sysadm_u account (my username has to be in the libvirt group in /etc/groups ! I don’t remember if that is set automatically) to do administrative stuff on the virtual machines (I find it more efficient for that than cockpit). Ironically, virt-manager can administrate the VMs but cannot open the virtual machines on themselves while they are running. As far as I interpret the data, virt-manager uses means that are no longer considered optimal practices (I avoid the term “best practices” here, it ain’t that worse) when it tries to access and channel the screen/display of the running VMs, unlike cockpit, and thus I consider the SELinux behavior as intended. But you can also focus completely on cockpit and use credentials that are from an account with more privileges to administrate VMs from within cockpit.

To maximize cockpit security when used only locally: ensure that only the intended user accounts are able to login (you can adjust cockpit’s config to determine which users are allowed / not allowed to login - I think this is done by default, but I don’t remember for sure), and I additionally removed the ports from the firewall’s open port list. This is “double security”, additionally to the credentials, but I like to avoid any single point of failure :wink:

Maybe something of that helps you to create an acceptable experience with virtual machines. As I said, I cannot help with GNOME boxes. Keep in mind that cockpit development is closely aligned with Fedora development, and it allows lots of cool stuff on Fedora. This makes it very stable and reliable at this point on our system. I do not know how closely GNOME boxes is considered in Fedoras evolvement, or if it uses interfaces such as libvirt that remain intentionally considered and tested on Fedora.

Hey Chris,

Thanks for the in-depth replies. I won’t bore you with details but I have had a brutal week in my classes (late stages of network administration degree)- I simply could not spare the time. This response will be short; I have yet to try what you have suggested, but I did want to answer a few of your questions and indicate that I do actually intend to contribute here.

I will try today using the sysadm_r role… I might try staff_u with that role as well, but I think sysadm_u is a good first step for every day use anyways. Security comes in layers and isn’t all or nothing; you try to harden but it’s always a tradeoff. One of the main reasons I started using Fedora is because of SELinux (pursuing RHCSA/RHCE and also because I’ve wanted to learn it for awhile now) though its become my favorite distro for a number of other reasons.

Using sysadm_r will make troubleshooting much easier- without having to logout and login to my “admin” user account (which I created as a precaution with the default unconfined_u mapped to it, of course), things should go much quicker.

I see you are also a KDE user. I like Gnome too but prefer KDE. To answer your question on the details of when KDE refused to load: installation (Fedora KDE Spin) was originally installed on new hardware about 1.5 years ago (November 24th 2022) and has been upgraded to the latest stable releases (now 39). I have installed this and that of course, removed a few things- nothing particularly drastic.

I am going to give getting a general setup on Workstation/Gnome a go using sysadm_u first, and then pivot to KDE Spin afterwards; I have 2 nvme boot drives exclusively for stuff like this so I don’t get myself in trouble :stuck_out_tongue: I actually wanted to use Silverblue since it appeals to me as a secondary option, but I recall reading somewhere that SELinux user confinement has more issues there.

Also on your second reply, I use a virtualization a lot; nonetheless I have never used cockpit (which of course I need to know how to use anyways, so I will take that suggestion). I too use virt-manager for maintenance related tasks, and for viewing a few VMs where screen space usage and performance isn’t important. I actually don’t really like Gnome Boxes much, but it has three significant advantages for me: it uses less vertical screen space than virt-manager’s titlebar/menu, doesn’t have scrolling issues, and for some reason is much more performant. In particular if I use Gnome as the wayland compositor in the guest, scrolling performance in a web browser (I do all web browsing in a VM) is solid. If I use kwin_wayland in the guest (or any wlroots based compositor) performance is abysmal; if I use virt-manager launched as a wayland client, I get scroll jumping (3 lines → 6 lines → 3 lines → 6 lines for each “click” of my mouse’s scroll wheel); I have to launch virt-manager in xwayland (‘GDK_BACKEND=x11 virt-manager’ so KDE/wayland → virt-manager in xwayland → Gnome wayland compositor in the VM) in order to fix the scrolling issue… or use Gnome Boxes which doesn’t have the problem.

Perhaps using Cockpit and a web browser will simplify all of this. Anyways, I’ll report back with my experiences :slight_smile:

Keep focused on your degree. Working and learning with SELinux shall support your degree, not risk it. Keep in mind that you can always contribute when and as much as you want. There is no expectation or obligation.

One widespread concept in academia (taught at every Information Security degree at some point :smiley: ) is to differentiate between the security of Confidentiality, Integrity, Availability. Especially the latter of the three makes you aware that security is almost always a compromise, which excludes both “everything” and “nothing”: e.g., if you don’t care for confidentiality and integrity, availability might be good immediately, but heavily at risk over time. If you impose to much confidentiality and integrity measures, availability might be at risk, too (effectively, you make your own “denial of service” against yourself). security of “CIA” is a concept that can be also discussed and it should not be taken for granted, but it facilitates interesting perspectives on “security”.

My personal goal is to make sysadm_u usable for everyone. In the Fedora use cases, I do not see much sense for staff_u and user_u. It also remains questionable if creating a stable reliable staff_u experience will be realistic at any time when user download and install additional packages. Fedora is used in different environments and thus has different needs than RHEL: the average Fedorians are themselves the admins of their machines. This already mutates the “return on investment” / compromise of staff_u and user_u. If we ever go so far that we aim to disable sudo and su in user accounts, much collaboration will be necessary with other teams, and if we do so, I think we will try to achieve it by other means than user_u and staff_u because they restrict things that are explicitly intended on Fedora. The SELinux user confinement has other purposes than restricting sudo/su for us, and these purposes are achieved with sysadm_u: even if it was captured by an attacker or so, my Firefox would not be able to access data of my terminal or of other processes. sysadm_u would make it rather crash than allowing that. What it could do beyond staff_u restrictions does not contain realistic means to increase its possibilities on my system or gather sensitive data as long as I am the sole (and thus fully trusted and 100% self-aware of what I actually did myself and what not) user of my system anyway.

F40 solves a lot of issues. If you want to save time, wait for the upgrade to F40 and then let us know again if the issues persist. It is likely that I set up my current working installation one release after you. Maybe there are some remainings that cause trouble. You might try to set up a new KDE Spin to see if the issues remain. Otherwise, you might open a topic at any time to gather more data and analyze the problem. Don’t forget to add the related data (ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today & journalctl --no-hostname --boot=0). Again, keep focused on your studies and do only contribute if you really have the time. You can do this if and when you have the time and have a “curious” moment :wink:

Personally, I find the experience of cockpit “improvable” (my feeling is that I often have to do more clicks to get the desired outcome - but I felt the same when I tested GNOME boxes a few years ago). But if screen space is a major point for you, cockpit might make you happy. I assume its experience does not differ much between KDE and GNOME.