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)

[py0xc3]

I have been working on my Fedora with confined user accounts [1] since January 2023: my user account (the one I use for my daily tasks/work) is confined with sysadm_u with x enabled (I need sysadm_u to have less restrictions on fs access; the user is not in wheel).

With this, I found out that much unintended behavior is caused by SELinux and some applications/functions are broken at all as long as the confinement is enabled. The issues disappear once the confinement is disabled.

I work with Fedora KDE Spin, so I started with the assumption that the issue could originate in the KDE SIG's configurations. We investigated this in an issue ticket at the Fedora KDE SIG: see issue 358. This ticket also contains some examples of confined-user-related avc denials.

However, as you can read there, the issue is not limited to KDE but appears also on the other Fedora editions/spins which I have tested so far (but I only tested KDE in an extensive manner), although each edition/spin has different occurrences: Fedora Workstation (GNOME) seems to work best, but at least file roller is fully broken (I only tested a default installation a minute or two, and opened some default apps and clicked some buttons, maybe there are more issues). The desktop of the Fedora Xfce spin is broken at all. KDE has some issues like buttons that don't work (e.g., shutdown button, but the terminal shutdown commands still work), and during the login, SELinux seems to break a process/function so that KDE waits for a timeout for 30 seconds before the desktop appears. Video conferencing through Firefox seems to be broken at all. Additionally, we found out at the ticket that the alignment of SELinux policies seems to be currently not in place the way it was expected by some. So maybe we have also a little organizational issue that we could consider in order to mitigate it or at least to raise awareness about it.

Yet, I also found out that confined user accounts can identify bugs in applications, so that we can achieve relevant data that we can provide upstream to get them fixed: within confined user accounts, one Firefox build from January crashed always when the right mouse button was clicked after the middle one was used to copy-paste without the clipboard. The reason was that any right click within Firefox triggered that Firefox tried to get once again access to the resource of the middle mouse click. This behavior always appeared when the account was confined, and never appeared when the account was not confined.

When testing with SELinux confined user accounts and when using them as a means to create a channel between SELinux-related teams and Fedora Editions/Spins-related teams, I think we can achieve two things:

On one hand, we can achieve an increase in security because we can improve the alignment of SELinux. Also, we can achieve that users who seek higher levels of security get an alternative to the currently widespread self-made snake-oil solutions, which are based on, e.g., GUI-containerization-approaches that often only work due to accidentally disabling most security features, whereas several approaches even added security issues. I have seen bad things when checking what people do to create seemingly more security. Being a Fedora Docs member, I would be happy to "capture" these users at a dedicated Docs page if we get confined user accounts usable. I would love to see Fedora "confinable by default" :)

On the other hand, we can collect data to identify bugs and issues to support upstream: even if some of these bugs/issues don't cause trouble without confinement, they could be exploitable vulnerabilities, or cause stability issues in future.

It might be noted that we have many security enthusiasts in Fedora (I regularly encounter them at ask.fedora, where I do moderation, and elsewhere): many of them are no experienced developers or security specialists, but helping to test Fedora with confined user accounts does not need much experience, but still gives them an explicit experience of contribution and enables them to add value, and it will be easy for them to collect and provide the related log data so that we can reproduce issues and adjust SELinux policies (we only need a short elaboration of what breaks in which environment, along with the logged avc denials).

Is there some interest to collaborate in this respect? So, to adjust, coordinate or supervise alignment of SELinux policies in Fedora? Obviously, this makes sense only in collaboration with the SIG/WG of the Fedora Editions/Spins, whereas people would test Fedora with confined user accounts in between SELinux-realted and edition/spin-related teams? (At the best, but not as requirement, testing would be done with having some people from the teams themselves involved in the testing).

@Conan-Kudo from the KDE SIG has already indicated a general interest to collaborate (see the above mentioned issue 358). I could imagine the other SIG/WG are interested as well. I think this can add value to both Fedora and upstream, and could add an interesting perspective in which applicable knowledge can be transferred (or even be created) in between the involved teams. I am a fan of providing well tested and reviewed policies that need as less non-reviewed customizations as possible in order to achieve the least possible permissions while keeping processes/functions working. At the moment, much customizations would be necessary, and I do not consider myself very experienced in tailoring SELinux policies in a "best practice" manner. I guess this also applies to many people in the Edition/Spin SIGs/WGs. So I expect that this is where your role would start.

Maybe we can use data from CentOS at some places since it seems to work much more stable with confined user accounts compared to Fedora. It is a different os but at some places comparabilities might allow us to transfer. But that might be less relevant in the initial stages of discussions.

I intentionally do not yet propose something more specific about how to organize/implement this. So far I just want to encourage a discussion and stimulate some thoughts/incentives without having anything predetermined ;)

[1] just to be on the same page about SELinux-confined user accounts:
https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/html/using_selinux/managing-confined-and-unconfined-users_using-selinux
https://danwalsh.livejournal.com/10461.html
https://danwalsh.livejournal.com/66587.html

[PhysicsIsAwesome]

Selinux user accounts are definitely an underused security feature. They are great to hinder malicious privilege escalation. I would also love to see improvements there, especially on the KDE spin. There are quite a few things which do not work and need fixing which cost each user a lot of time.

Did you or anyone else find a fix to the shutdown/logout button not working on KDE?

Switching wifis or logging into one does not work on user_u. Not sure if this is on purpose.

Flatpak/Bubblewrap also deperately needs its own policy to work with user_u (preferably with MCS to separate different Flatpaks from each other). More and more apps get published on Flathub, so this is a major usage point.

[zpytela]

Hello,

Policy for the staff_u and user_u users are used, updated, and tested the most, together with the sysadm_r role for the staff user. If you encounter any particular problem, please report it with reproducing steps, additional settings required, and audit logs after the scenario fails like

# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Users with MCS were not tested much so far, we are looking forsome reasonable scenarios.
Documentation for RHEL 8 and 9 improved in the past 2 years substantially, awaiting the next update in 1 or 2 weeks.

[py0xc3]

@PhysicsIsAwesome You can check the avc denials of the log of the very time an issue occurs. The denials usually offer you a suggestion how to allow the very behavior if you want to make it working immediately (I keep working with the terminal in such issues). I would prefer to not change such things on my own but to discuss, review and test a common solution (we can do this here, maybe it makes sense to open a dedicated thread for elaborating the specific denials ;). The immediate suggestion of SELinux is not necessarily the best one (e.g., in terms of least privileges), and maybe it proves in some cases more suitable to adjust the system at some other point than the immediate point of denial.

Btw, I am not sure about your use case / consideration for flatpaks, but since you mention it in a security context: be aware that flatpaks are not necessarily an increase in security:

On one hand, you replace the consistent homogeneous/standardized building and testing of Fedora with the inconsistent (or even unknown) heterogeneous building/testing of many different flatpak provider. This would be also a problem when we would try to more precisely/deeply consider flatpaks in confined user accounts or SELinux at all: the flatpak providers tend to not consider conditions on the operating systems or its mandatory access control (and many don't consider security at all) so that we practically need to use one setting/configuration that has to fit all flatpaks (which leads to compromises). I am not sure how the flatpak technology works, so I don't know if SELinux confined user accounts can at least separate different flatpaks from each other as they do it with other processes (and confined accounts can indeed extensively separate processes from each other! See the Firefox example above), or if all flatpaks are a "common environment" from the kernel perspective, so that SELinux can only consider the whole flatpak environment as "one thing" in which different flatpaks are separated only by what the flatpak technology imposes (this would be especially problematic when also considering the point of the next paragraph). So if the kernel can consider each flatpak individually, you do not need to have MCS to impose an additional separation through SELinux. If the kernel cannot, MCS would not be able to change that.

On the other hand, most of the flatpak providers deploy their flatpaks with configurations like filesystem=host, which disables most of the security advantages of containerization. This does not mean you should avoid flatpaks or so (it has obviously advantages, too), but in a security context, we have to be aware that using flatpak does itself not lead to an increase in security.

---

@zpytela Thanks for teaming up. That sounds good! As you have seen in the two tickets here and in pagure, I have already started to collect issues. Once I have some time, I will open a new ticket here (or somewhere/something else?) with an elaboration of what is the issue, how to reproduce and with the related denials and log entries.

---

Btw, I have just had the second example where my confined user account revealed an issue that could not be uncovered by other means -> in the new cockpit version [BZ# 2229146], [FEDORA-2023-34f212e4ae]:

This is neither a "real" bug nor a security vulnerability, but the new cockpit version has some changes in its behavior that are not desirable and that have not been known. The cockpit team aims to adjust cockpit to get rid of the undesired behavior if possible.

---

I think I will open a topic in discourse once I have some time in order to identify if there are more security enthusiasts that are interested in using and helping testing with confined user accounts. If we find some people, I can set up a related page (or a SIG page, which might make sense at this point) to let them know what this is, how to join, how to test and how to provide feedback/reports. I would be happy if we can setup at some point a page in our actual Fedora Docs to provide confined user accounts to security-oriented Fedora users also on average production systems.

[py0xc3]

Sorry, accidentally closed -> re-opened now.

[PhysicsIsAwesome]

@PhysicsIsAwesome You can check the avc denials of the log of the very time an issue occurs. The denials usually offer you a suggestion how to allow the very behavior if you want to make it working immediately (I keep working with the terminal in such issues).

Sometimes it's not as easy: #1829

I also opened a few other issues and more will follow.

I would prefer to not change such things on my own but to discuss, review and test a common solution (we can do this here, maybe it makes sense to open a dedicated thread for elaborating the specific denials ;). The immediate suggestion of SELinux is not necessarily the best one (e.g., in terms of least privileges), and maybe it proves in some cases more suitable to adjust the system at some other point than the immediate point of denial.

I also would prefer a solution vetted by a Selinux expert, but as long as there is no such fix, I will open an issue and meanwhile fix some things on my own.

Btw, I am not sure about your use case / consideration for flatpaks, but since you mention it in a security context: be aware that flatpaks are not necessarily an increase in security:

I am aware of some of Flatpak's security limitations, like the seccomp-filter, overly permissive default permissions for many apps and the third-party problem, but would prefer to not discuss this here. I still occassionally need to run an app via Flatpak and it's getting more and more common in the Linux world, so it should be usable.

I am not sure how the flatpak technology works, so I don't know if SELinux confined user accounts can at least separate different flatpaks from each other as they do it with other processes (and confined accounts can indeed extensively separate processes from each other! See the Firefox example above),

Could work with a similar approach to how Selinux confines containers, which also uses MCS to seperate containers running under the same domain. Containers and Flatpak use security-wise the same Linux features and have a similar wide range from being quite confined to almost full system access.

[py0xc3]

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