SELinux provides a strong security measure that can make an SELinux-enabled operating system a type of “fortress”: the so-called “confined users”   , which add security and isolation capabilities that are in several respects comparable to containers but without many of their restrictions in GUI use cases (this topic is focused on desktop use cases, not server, infra, and such).
By default, SELinux does not enforce much within user accounts but only around them. But in graphical desktop environments, a lot of processes are running along with each other, each with the potential capability to harm the others or to steal information. Confined user accounts can mitigate that.
Account confinement makes SELinux to enforce a strong isolation and protection of processes, users/services and their data within/among accounts that are confined.
This achieves some of the goals of security-oriented containerization, while Desktop containerization solutions like
flatpak disable many security features because containerization and GUI in conjunction with each other tend to provoke security-impacting compromises in order to provide a sufficient user experience - this includes also most self-made podman-based GUI-containers I have seen so far (additionally, GUI-containers sometimes even introduce some new security issues). Further, SELinux is much more powerful than containers in desktop use cases, but also more flexible and capable to be tailored more precisely to a given environment.
Being made with and for SELinux, Fedora supports confined user accounts. However, when doing some testing, I found out that our SELinux policies are currently not sufficiently aligned, which leads to some issues when using confined users (see  & ), whereas KDE and GNOME are “usable” with limitations, while at least Xfce is broken at all when accounts are confined. I have not yet conducted tests with Silverblue / Kinoite, which could also profit if this capability gets tested towards maturity on immutable desktops (another user already started to test confined user accounts in conjunction with
toolbox containers → thus, to use confined user accounts to achieve the strong security/isolation without risking the user experience of
toolbox through GUI/containerization restrictions).
Having talked with people from KDE  and the SELinux team , our goal is now to foster the alignment of SELinux policies in order to make Fedora and its editions and spins fully compatible with confined user accounts: this enables security-oriented users to “confine” their Fedora accounts, which makes the operating system to a “personal fortress”, in order to fulfill highest security demands
We seek users who are interested in working (and thus testing) in confined user accounts and who report if they experience issues. The latter does not need much knowledge: just test, and once you experience an issue, document the issue, how this issue is provoked and in which environment it occurs (which primarily means: how to reproduce it). Then add the log extract of the very time the issue occurs (it is not yet clear if the logs of journalctl or the limited output of avsearch is preferred). Explaining how to get the log will be no problem in either case (it should be not more than one terminal command).
Furthermore: confined user accounts have already helped to reveal bugs and issues    because they enforce secure practices and can break processes when unintended or disadvantageous behavior occurs (may it be because of a bug, or because of disadvantageous architecture/programming issues).
This can help us to provide valuable incentives upstream to help to make both Fedora and its packages more secure and reliable. Testing with confined user accounts has so far identified an issue with
cockpit  that is not critical but that is aimed to be solved in future versions to improve
cockpit’s security and stability.
A Firefox issue
Firefox issue   has solved itself in the respectively next version, but it has shown how strong but also precise SELinux confined user accounts are: when Firefox tried to access text in the terminal without user prompt, SELinux denied the access so that
Firefoxcrashed. With user prompt (through middle-mouse-click to copy-paste without clipboard), SELinux allowed it.
Obviously, this can also help to improve the SELinux policies for normal Fedora installations since confined user accounts can reveal issues that also affect normal accounts but that do not cause obvious effects without confinement.
I wrote in the topic (SIG) in brackets: generally, everyone can just start to use confined accounts and open tickets at the GitHub repo of the SELinux team if they experience issues (but please check in advance which information is requested and in which format; feel free to ask also here in discourse → if necessary, we can create a tag in ask.fp that I can monitor). However, if people are interested to contribute but feel insecure when doing this on themselves, or if people feel the need to coordinate and exchange, I have no problem with making this a SIG.
In that case, I can provide a Wiki page in the coming months about how to get the confinement done, how to test and what to consider, but if necessary also a board to consolidate efforts/data and to elaborate/exchange issues before filing them at GitHub. Everything is possible. Feel free to let us know your thoughts.
The first reports can be reviewed .
 Confining the User with SELinux - Dan Walsh's Blog — LiveJournal
 Chapter 3. Managing confined and unconfined users Red Hat Enterprise Linux 8 | Red Hat Customer Portal
 Difference between a Confined User (staff_u) and a Confined Administrator. - Dan Walsh's Blog — LiveJournal
 Issue #358: KDE Spin/components not properly aligned with SELinux (this can be verified with SELinux confined user accounts) - SIG - Pagure.io
 Tests with SELinux-confined user accounts show that SELinux is not properly aligned on Fedora (and maybe there is an organizational issue, too): an approach to mitigate the issue and to exploit some synergies (and to facilitate some knowledge transfer & creation) · Issue #1805 · fedora-selinux/selinux-policy · GitHub
 2229146 – Login not possible with Python bridge with user_u restricted user accounts and user_exec_content==off
 Issues · fedora-selinux/selinux-policy · GitHub
Some slight technical incentives in advance to avoid lockouts when you test too early on production systems (this assumes you already worked through the above links):
If you want to test confined user accounts: You can use the pages I provided to learn how to get accounts confined. It’s just a few commands in the terminal. However, for many Fedora users, the confinement with user_u and staff_u profiles is too much and might hinder their work. A compromise to keep Fedora behave the way it used to behave and still impose confinement within accounts is to use sysadm_u → but for sysadm_u, you need to enable the related GUI-boolean (xdm_sysadm_login) to allow sysadm_u to work in graphical accounts (the Red Hat-related pages elaborate how, but feel free to ask if you are unsure). Another possibility is to combine staff_u and sysadm_r (“r” instead of “u” at the end; you will find sufficient on the Internet with the two terms in your search query), but understanding of the latter might need some related skills in advance.
When you want to confine in your “production” systems and to impose “full scale” confinement, you can also confine the default profile to ensure that every account that is somehow used is confined (not just user accounts). E.g., user_u for default and and more privileged profiles for your own user account (at least staff_u is necessary to be able to use
sudo in the given account). In all cases I suggest to enable the root account in advance and to keep it unconfined (unconfined_u) in order to ensure that you do not lock yourself out (at least until you have some basics with confinement), or alternatively keep/create an account that is in the
wheel group to use
sudo while at the same time set that account explicitly to unconfined_u.
You can go one step further to even more increase security and disable the exec content booleans (*_exec_content), which identified the