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 ). 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.
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.
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
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).
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:
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
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
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.
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 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
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 ) 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
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.
After my brutal week and then last response, I experienced (what seemed like) a significant injury, had more brutal class stuff emerge, and haven’t done anything with SELinux. Finally I have a month off before more brutal classes emerge so I will be able to finally do some experimentation and post my results here.
As an aside I won’t be able to do this for KDE because 6.1 was an immediate nightmare of bugs. Since I planned to do SELinux stuff anyways and figured a known-state/clean-slate was important (and that Silverblue has more challenge points with respect to user confinement), I wiped it and installed Workstation. I now have a few month old Silverblue install, and Workstation has only been used a month- should be reasonably close to expected with respect to state.
I’m also hoping to explore and better understand SELinux confinement with respect to virtualization. For instance, from a security standpoint, is it better to use qemu:///system or qemu:///session given that SELinux provides type enforcement for both (and system_u/system_r labeling for qemu:///system qemu instances, network devices, etc)? This is complicated because qemu:///system sees a qemu process that runs as user ‘qemu’ under the DAC model whereas qemu:///session sees the qemu process running as user (so with more privileges than system). When you look online, security really isn’t mentioned in the comparison of the two. This is part of the problem with what you/we are trying to do in terms of confined user accounts- security just really isn’t very popular and its a lot of trudging along in the dark on your own. I probably should start a thread on this, but I doubt many would answer since so few are focused on security for its own sake.
I did get a chance to mess with Cockpit- pretty neat. VNC performance is abysmal in terms of the console though; I’m assuming connection to a VM with spice should be done via some remote client as opposed to just in the browser? I’ll have to play with it more later.
I’m going to try and duplicate my current running environment tomorrow but in a confined user account and we’ll see what happens; I’ll report back (this time, actually).
@py0xc3 After doing some initial testing, I want to clarify a few things.
First, do we have a page with concrete goals to pursue? By goals I mean “establish baseline of how Fedora Workstation works with sysadm_u ”, “establish baseline of how Fedora Kinoite works with user_u ”, etc. I am looking at the Confined Users SIG, and there is no organization structure with respect to information gathering. It will be largely chaotic if the information is gathered across a number of threads on this discussion board, in a chat room, etc.
Second, is the matrix channel active? I’ve never used Matrix but I can if a lot of the legwork is done on that channel.
Third, I’ve decided that instead of just Workstation, I am going to test Silverblue, Kinoite, and the KDE spin in whatever way is established by some organizational informational structure. I have 3 nvme SSDs on my computer; 1 has Workstation, 1 is a backup/storage drive, and the other is another “boot” drive (formerly had KDE spin on it). I had intended to use it to BTRFS RAID1 with the other nvme drive, but I’ll keep it for testing in this SIG instead. I’ll start with Workstation as it’s the “flagship” and most tested/used of Fedora’s offerings, but as someone who prefers KDE I really hope to get KDE Spin/Kinoite functional at least on sysadm_u. FWIW I have pretty ideal hardware for testing: AMD gpu and no proprietary out-of-band driver stuff is needed on my install.
I am aware that the immutable variants have more issues, yes? Is there any resource we have that explains why, whether elaborations of policy might mitigate the issues, etc?
Please open a new topic in Project Discussion with the confined-users tag.
Generally, the goal as far as it concerns the sysadm_u is to work and test it, and prepare and submit tickets at the place where these are tackled and consolidated: the github repo of fedora-selinux. Or bugzilla (product “fedora”, component “selinux-policy” → here).
Tickets of current/open issues are consolidated there. Not sure what you mean beyond that, we don’t have other goals than the SELinux people, we are (at least as far as it concerns the SELinux part of our SIG) a contributor and service provider for SELinux-policy and decide which part of that product we primarily/mostly contribute to (and how) and thus impact the emphasis & evolvement → the current emphasis & goal is documented in our wiki page (I set this, but of course it can be changed/specified if members prefer something different - I just wanted to “initialize the discussion”) → get sysadm_u running smoothly by default, and maybe in later future, facilitate a smooth use of user_u/staff_u while working without root/sudo (which is what links us to the non-SELinux part of the SIG). However, feel free to elaborate in a new topic in Project Discussions if you mean something different, or if you have other ideas to improve or change the SIG. But this one is an ask-topic In any case, I would love to see a new discussion about how to evolve and in which direction Much has happened & changed since the last one.
It might be indeed useful to improve and extend the SELinux/ConfinedUsers wiki page to include sysadm_u and how to enable x by default, so that we no longer rely on RH docs pages (although I find the related RH docs very good - so I would not consider this a high priority - I have to focus at the moment on other things unfortunately and have to prioritize).
I have also on my list to update our own SIGs/ConfinedUsers wiki page and remove the idea of tickets in pagure. That seems neither reasonable nor practically used as far as it seems at this time.
If there is more data that new (or existing) members need, we might add it to the wiki too. Technical stuff to the SELinux/ConfinedUsers page, and SIG/organizational stuff to the SIGs/ConfinedUsers page. Discussions about anything (may it be stuff related to the contents of the two wiki pages, or existing, current or upcoming github-tickets/bug-reports - including evaluation about if/what/when to create some new ticket/report) belong here imho (feel free to challenge that thought ), to confined-users of project discussion, or in case of technical questions, selinux-confined-users of ask.fp
We maybe should also link the two wiki pages once they are suitable for that.
Not terribly familiar with Red Hat’s Bugzilla, but I will work on it. For certain I will at the very least dump data to a thread in Project Discussion with the confined-users tag.
I had looked into to the details of the different SELinux users and I’m with you- sysadm_u is really the only thing reasonable at least in the short run. I did figure I would gather data on the others, but for now I will try to more elaborately test sysadm_u, especially with virtualization and some common apps that many users care about (e.g. VPN clients, steam, wireshark, etc).
Believe me I understand this.
I noticed in the other reply you made that you test mostly KDE- does this include Kinoite? I think then on KDE I will check some of the more non-standard stuff (like I said above: VPNs, etc), and if you don’t test Kinoite, I will test that elaborately as well. Otherwise it might be best if I maximally test Workstation and Silverblue since most of the userbase is there.
). 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.
) 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”.