How to enable SELinux user confinement? What to consider?

Ask Fedora
1

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 toolbox and 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.

How to enable this on Fedora? What to consider?

(this topic is intended to constitute the selinux-confined-users tag)

2

SELinux confined users can be used on Fedora without installing anything new, but they have still to be considered testing (not because of SELinux but because the policies that are relevant within user accounts have not yet been sufficiently aligned → unintended denials are possible; e.g., video conferencing in browsers does not yet work in confined user accounts). The Confined Users SIG is currently working on improving this means with the goal to make it stable and ready to be used on Fedora releases by everyone (but also other types of user confinement).

A general elaboration of how to enable SELinux confined users can be found here: Chapter 3. Managing confined and unconfined users Red Hat Enterprise Linux 8 | Red Hat Customer Portal

The semanage commands work on Fedora the same way as on RHEL.

On Fedora, the initial goal is to make sysadm_u profiles working for everybody, but this makes it at the moment necessary to set this profile’s xdm_sysadm_login boolean to true in advance (to enable the sysadm_u users to use the GUI). Although it sounds like increasing privileges, sysadm_u does only increase confinement, and it does only limit privileges but does not add any: it introduces most of the SELinux enforcement into the user account (but it doesn’t touch su and sudo capabilities, and it still allows some outreaches that are necessary for, e.g., cockpit webinterfaces, in which users sometimes want to log into cockpit with different user accounts). user_u profiles do not (yet) make sense without enabling the root account (or any other account that is unconfined and with the possibility to sudo) IN ADVANCE.

It is suggested to get a little deeper into the topic BEFORE imposing SELinux confinement on users. Especially, if you do not know for sure what you do, keep an unconfined user that is allowed to sudo, or enable the root account before confining other accounts (and at this time, if you enable root, do not confine root on Fedora).

The initial post of the “constituting topic” of the Confined Users SIG might be interesting and gives a good overview of what this is, what to consider, and what links to follow: Security enthusiasts wanted: from beginners up to SELinux experts to make up the SELinux "Confined Users (SIG)" to foster Fedora's security capabilities

Additionally, it might be interesting to read the page of the Confined Users SIG: SIGs/ConfinedUsers - Fedora Project Wiki

3

Removed flatpak, selinux, server

4

Do you have more information on this? I have a thread here where I attempt to change the SELinux properties of a toolbox container, and it apprently requires and act of God to do so.

5

Generally, toolbox should work by default today, even with confined accounts (I use it with sysadm_u). I think there were still some restrictions in user_u, but I do not have the very case in mind atm. There used to be an issue at some time, where after an update a specific fedora container version caused a denial (I don’t remember the details; I filed that long ago), but that was simply solved by creating a new container (that was already some time ago, and it occurred ONLY IF THE ACCOUNT WAS CONFINED). There should be no issues with toolbox, especially if you are in an unconfined account (which I assume you talk about?).

Can you be more specific? Or give a link to the topic?

6

So in this example, ( which I have as a low priority project atm ) I start the toolbox, get fedora:latest , download, installa browser that i want confined to the toolbox ( including packages ) and change it’s SELinux properties.

I did manage to do the install but was stuck at keeping packages inside the toolbox and changing selinux properties. Those I can do from a rootful container but not toolbox. . . There’s a lot more I can add here . . .

I guess another question is can you change SELinux context for things inside the toolbox?

7

It seems I already made several comments there :smile:

I have not read the whole topic, but a few bullet points (in case they have not yet been made):

  • I assume you know toolbox is explicitly not intended for security purposes. A toolbox container has even read access to the root file system through /run/host/, and it can also adjust user files (dangerous when, e.g., manipulating files like .bashrc or so).
  • If you have SELinux issues, you might also check out the underlying technology: podman - there is a lot around about how to make podman containers working with GUI. That might give you understanding of the underlying issues. And information available about that could also apply to your issue. There is also much about SELinux & podman in this respect (Dan Walsh is involved in the development of both :slight_smile: ).
  • beyond that: get the behavior, errors and the related denials, and analyze them in their context. sudo journalctl is helpful for that because it shows you exactly also what happens before and after the denial. However, I am myself a friend to seek standardized SELinux policies.

SELinux itself should not make a difference between inside and outside the container. All are just files that are stored in your user directory. The user in the toolbox can impact profiles the same way the user outside can do. Don’t forget that root in the container is effectively only your normal user account.

I never tried to access the container root file system from within the container through its folder in ~ (the root filesystem as shown in the container is effectively just a folder somewhere in ~), I indeed do not know if toolbox imposes any restriction at this place, or if the user in the container can modify its own root file system when bypassing the / path through the home path. As I said, toolbox has no intention to be used for security-related containerization. So that’s not just about SELinux.

Everything else should become a separated topic :wink: (if not more than one)

1 Like