Security enthusiasts wanted: from beginners up to SELinux experts to make up the SELinux "Confined Users (SIG)" to foster Fedora's security capabilities

Project Discussion
,
1

SELinux provides a strong security measure that can make an SELinux-enabled operating system a type of “fortress”: the so-called “confined users” [1] [2] [3], 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.

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 [4] & [5]), 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 [4] and the SELinux team [5], 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 :wink:

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 [6] [4] [5] 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 [6] 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 [4] [5] 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 [7].

[1] Confining the User with SELinux - Dan Walsh's Blog — LiveJournal
[2] Chapter 3. Managing confined and unconfined users Red Hat Enterprise Linux 8 | Red Hat Customer Portal
[3] Difference between a Confined User (staff_u) and a Confined Administrator. - Dan Walsh's Blog — LiveJournal
[4] Issue #358: KDE Spin/components not properly aligned with SELinux (this can be verified with SELinux confined user accounts) - SIG - Pagure.io
[5] 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
[6] 2229146 – Login not possible with Python bridge with user_u restricted user accounts and user_exec_content==off
[7] Issues · fedora-selinux/selinux-policy · GitHub

Additional links:
SELinux/Debugging - Fedora Project Wiki
SELinux/ConfinedUsers - Fedora Project Wiki

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 cockpit-related issue.

13 Likes
2

I’d love to be part of it (although I’m not able to do much more than testing). I’ve always heard high praise for SELinux and it always felt weird that we never confined much in Fedora and that we don’t see a lot of people creating policies for it, specially with all the love for solutions like Firejail in the Linux community at large.

I know I’d like to at least help spread the word with the help from the rest of the Marketing team.

1 Like
3

I would like to help with this effort @py0xc3 , as I have always felt SELinux was an underused security tool by many in the community and the desire to set enforce=false seems to be the hammer everyone reaches for. The subtlety of ACL’s is something that is not easy to learn from the tradition Linux user POV I think.

1 Like
4

I’d like to be part of it!

5

I’m pretty interested but I need to know if tests can be conducted in VMs?

6

Most of activities use the same resources on a physical or virtual machine. There might be a difference when using sound, acceleration, etc.

Note we now have a page to help with debugging [1], basics of confined users setup are also described [2].

[1] SELinux/Debugging - Fedora Project Wiki
[2] https://fedoraproject.org/wiki/SELinux/ConfinedUsers

3 Likes
7

Just my 2¢, but IMHO one significant thing that SELinux needs in order to advance is a good graphical tool that the admin can use to easily determine what rules are currently in effect and to modify and add to the rules. The sesearch command is a good start. But I’d really like some sort of graphical representation of the information with sources and targets and lines between them to indicate what is being allowed. Without such a tool, I feel hopelessly lost in SELinux’s vast sea of rules.

A quick search suggested something called policycoreutils-gui (which I haven’t used before). But it doesn’t seem too promising.

Installed:
  policycoreutils-dbus-3.5-1.fc37.noarch                                                         policycoreutils-gui-3.5-1.fc37.noarch                                                        

Complete!
[/home/glb]$ sepolicy gui
org.freedesktop.DBus.Python.dbus.exceptions.DBusException: Not authorized
[/home/glb]$ sudo sepolicy gui
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified

(sepolicy:1796444): Gtk-CRITICAL **: 11:02:00.771: _gtk_css_lookup_resolve: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((provider)); GType __t = ((_gtk_style_provider_private_get_type ())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed
/usr/lib/python3.11/site-packages/sepolicy/gui.py:135: Warning: g_object_set_data_full: assertion 'G_IS_OBJECT (object)' failed
  builder.add_from_file(glade_file)

(sepolicy:1796444): Gtk-ERROR **: 11:02:00.772: Can't create a GtkStyleContext without a display connection
Trace/breakpoint trap

FWIW, I’m running Sway.

4 Likes
8

Would like be part of this. Have a good bit of experience with SELinux in RHEL in an enterprise setting.

9

Any contribution is appreciated! And testing would be already the major task in this project anyway :slight_smile:

As Zdenek already indicated: yes, you can. If you have made relevant modifications to your host Fedora (e.g., changes in configurations of the desktop environment or so), I even suggest to create additionally a VM with a default Fedora (with the same desktop environment) to test if the “default” of your desktop environment in Fedora experiences the same issue than your modified host (I do it that way) before you file an issue against github. Of course you can focus your tests in the VM without a host.

The different hardware of your host and a VM is unlikely to affect what we test here, since the differences between confined and unconfined users will primarily affect user space. However, it cannot be excluded of course - and this would be interesting and worth to be filed as well.

But it might be noted that if the host user is confined, this can affect the use of VMs. I experience issues with virt-manager when it comes to displaying the screen of the VM, but I migrated to cockpit and I am not sure if I want to open up the privileges for virt-manager since cockpit is sufficiently able to do the job, while I would prefer to change virt-manager to fit the security architecture rather than open up the confinement (I have not yet fully evaluated the issue with virt-manager). Obviously, now there is also the new issue with cockpit (the one noted above) :rofl: But hopefully, user_exec_content can be disabled soon again for cockpit.

Thanks ! I added it to the topic.

1 Like
10

I had this, it’s a problem with user permission, tomorrow I can brief you in how I solve it

Count me in!

1 Like
11

I understand your point, but I am not sure if a graphical tool woud be a good complement.

Driving a car with broken brakes is less dangerous if the driver knows about the issue compared to if the driver does not know about the broken brakes.

What I mean, if people disable SELinux, they at least don’t expect the related protection. But you can have SELinux enabled but still “effecitvely disable” it by “liberal policies”. SELinux is a great thing, and maybe the most powerful but still most adjustable/“tailorable” MAC for Linux, but one of its disadvantages is its complexity. When users just “test” and open up privileges until it works, it is possible that they effectively already disabled SELinux. Graphical tools can foster such negative developments (I am not worrying of users who are not yet sufficiently experienced to understand THE complexity of SELinux policies, but about the users who are not yet sufficiently experienced to understand THAT there is complexity and thus that this is not a trivial task). So the absence of graphical tools can be seen as advantageous “entry barrier”. The major difficulty is the architecture and thus the “reasoning” of SElinux imho, and graphical tools cannot mitigate that anyway.

However, this complexity is one of the reasons why I put forward this suggestion: make SELinux be appropriately configured by default, so that users do not need to adjust it themselves, but just choose if they want to remain unconfined or get some level of confinement.

Given the complexity of SELinux policies within an os, I tend to prefer in general that SELinux policies get professional elaboration and public review, and consolidating related data and solutions at our SELinux team achieves that best imho. But in the end, everything is just a compromise obviously :wink:

12

I can’t really argue with that. :slight_smile: And I’m fine with that approach as long as the end user has a reasonably easy way out when they just need something to work regardless of the security risks.

So, in that case, I guess my request is that this new SIG be diligent about creating well-documented SELinux booleans for the security policies you create so we “laymen” end users can switch things off reasonably easily when we must. To-date, I’ve been able to (for the most part) manage with switching booleans on and off (though I’ve seen a few that seem much too broad in terms of what they allow).

13

No one can argue with the broken brakes :sunglasses:

But I indeed did think only about making/adjusting policies or roles and such. The booleans are indeed an issue that needs better documentation. The goal should be definitely that average users don’t need to manage the booleans, but users who have more specialized needs could be able to adjust their booleans more appropriately (and with less deterrence) if there was a more comprehensive documentation. Not sure if a GUI would make a difference here since I find semanage comfortable for the boolean adjustment itself, but I guess for the boolean-purpose a GUI would be not as dangerous as for policies/roles and such. An SE-boolean GUI could offer a stronger/immediate link to documentation (if existing) compared to command line stuff.

Unfortunately, I assume this project here is unlikely to change the boolean issues. At the best, for a few booleans that are relevant for more widespread use cases (such as the mentioned *_exec_content or so). But we cannot repair all brakes :frowning:

Indeed, fostering “SEdisable” or even switch-distro-behavior should be avoided. There is no plan to make confined user accounts a default. It is something that users who want or need this security level can enable themselves.

I would say that the “highest” achievement would be, if we at some point can ensure that the policies are aligned and remain maintained throughout, this could become an opt-in possibility with a short explanation (so, keep it disabled if the user does not enable the tick) in the installer in applicable editions/spins (but even this possibility is not realistic at this time :wink: ). What we learned in the past (in general, not Fedora) is that users need to be convinced of and educated to security, not forced.

14

Please forgive me if I am missing something, but for this all we are doing is testing various confined users (i.e. sysadm_u, staff_u, user_u, and guest_u) and providing feedback and bugs/issues? Or are we building confined users and testing then to better build out processes?

15

Well, you can test confined user accounts to get some understanding of SELinux and to contribute to Fedora, and if “things” that work without confinement do not work with confinement, you get the related data and open a ticket at our SELinux team’s GitHub repo so that we achieve at some point that confined user accounts work as good as none-confined-accounts.

But you can also use confined user accounts in production (I do so) because they are already “usable” (but with restrictions) and provide much more security than unconfined accounts. Especially when you handle private/classified information, you have to be aware that in graphical desktop environments, you “more or less” trust all processes that run in the GUI. This poses a risk that can be mitigated with confined users. However, at the moment, as mentioned, there are restrictions on Fedora, and it would be cool to get rid of these restrictions (which first means to identify them) at some point to also enable average users to use confinement :wink:

In any case, if policies look good despite a denial, or if something that used to work does no longer work after an update, it might be worth to think if this is really a SELinux issue, or if the package has a problem. If the latter is true or indicated, this is a normal bug report at bugzilla or so (of course the environment in which an issue occurs needs to be described, which then includes the confinement).

Thus, this is something for that we do not need meetings or so. Everybody can do this on themselves. If we make this a SIG, the SIG itself would be only to propagate this opportunity (both to test/improve it, but also to use it), and to help those people who feel not sufficiently confident to do this on themselves. May it be that they are usure how to get confinement done securely/stably, or may it be that they are not sure how/what to file at the SELinux team’s repo. So this would be a very informal SIG without much “onboarding” or so.

As far as it concerns me, anyone who wants to be in can say “hello I’m in” in this topic, open topics in ask.fedora with the #confineduser tag (the first user will have to create it; should be possible by any TL1+ user in ask.fp; once a user created the tag, they should mention it here, so that I and everyone who wants can start monitoring the tag) when it comes to technical questions. Additionally, I can create a pagure repo that everyone with an FAS account can use to open tickets: may it be a ticket for issues they experience or are unsure about, or tickets if they are not sure what/how to file at the upstream repo from the SELinux team (this would be also to decrease a little their workload).

Theoretically, I do not think we need more than that (I am not sure if these things will be used much, but this can offer some confidence without much investment). I will monitor the ask.fp tag once created, and also the pagure repo to ensure no one gets lost. Everyone is free (but not obligated!) to do the same.

However, it is always good to give people some reward for contributing, so it is possible to also create a pagure group for the repo, where we can add people to have their contribution somehow mentioned. Let me know your thoughts if you want. I can create that.

1 Like
16

I created a pagure repo for now: Overview - SELinux-confined-users - Pagure.io (let me know if I shall create a group in order to add members)

We might also create a short entry in Category:SIGs - Fedora Project Wiki but I don’t think we need a page on its own: just a section on the major page. It is just to inform that the opportunity exists (both to contribute and to use it), and to link the pagure page and this discourse topic, and mention the possibility for #confineduser topics in ask.fp when it comes to technical “how to get X done in Fedora Linux” questions.

Anyone who can spare a minute is free to add the section to the wiki page, otherwise I might spare a few minutes in the subsequent days.

It would be also nice if someone can open a ticket in the pagure repo to test if I get notified.

2 Likes
17

Category:SIGs - Fedora Project Wiki

People who use and/or test SELinux’s user confinement in Fedora in order to improve SELinux policies to increase security and user experience (including for default Fedoras without user confinement). Also, the SIG aims to make the “confined user” capability as smooth as the Fedora default without confinement so that confinement becomes usable by average users. Additionally, the SIG aims to propagate the possibility/capability about user confinement but also about the possibility to easily contribute to that. This SIG is for all kinds of security enthusiasts, from beginners to SELinux experts. It is very informal: contributors might review the discourse topic (especially the opening post and this one) and say “Hi” in the topic. For any kind of help about user confinement or related reports, feel free to open a ticket in our pagure repo, or use the #confineduser tag in ask.Fedora for technical “how to get X done in Fedora Linux” questions. The SIG has no meetings.

Feel free to adjust.

18

If anyone has issues with using/adding bluetooth devices in KDE: I reported the issue. You can mitigate this easily without modifying yourself the policies:

You can use and connect to devices properly with confined accounts, but only if you have added the device when the account was not confined. This means, if you have an issue with adding or connecting a bluetooth device, I assume it was added when the account was confined. Thus, remove the device, then make your user account for a moment to unconfined_u, reboot, login and then add your bluetooth device just as usual. Once you added the device and properly connected to it the first time, you can confine your user account once again with your preferred confinement (user_u, staff_u, sysadm_u, …), reboot, and then you should be able to properly connect to this device in future.

I am thinking if it makes sense to create a page, a pagure repo or something like that, in order to elaborate mitigations/workarounds for those using confined user accounts. Finally, it can take some time before a reported issue can be solved.

19

This looks like a bug in the SELinux policy. Could you see if there are some audit logs and file a bug?

20

I have already reported it to the SELinux team [1] [2] with related
details. I don’t know for sure yet but my current guess is that the
actual problem caused by the policies occurs much earlier: during the
login. There are several denials during login, and later on there are
several functions (not just bluetooth, also buttons like shutdown or
reboot) that do not work and where only user logs seemingly indicate
something in plasma/kde to be broken or wrongfully implemented. There
are no avc denials at the very moment, nor root logs at all.
Nevertheless, the issue occurs only as long as the account is confined.
So its clearly related. But the details including the kde/plasma-related
user logs of the very moment [1] are in the github tickets.

There are several such bugs in the SELinux policies (some are already
reported ).
But since the default profile used in all Fedora editions/spins
(unconfined_u) does not enforce much within user accounts, most remain
hidden until people start to work with confinement. But this is why I
founded this SIG. On one hand, to make Fedora work properly with SELinux
user confinement. On the other, to improve the policies in general, (and
sometimes also to identify bugs in packages because some denials occur
for good reasons).

For now, we agreed to keep this in the GitHub
repo of the
SELinux team. But feel free to let me know if there are some other needs
/ preferences from the side of the KDE SIG in order to remain/get
involved/informed.

[1] Selinux user_u on KDE: logout, shutdown, reboot buttons not working in start menu · Issue #1829 · fedora-selinux/selinux-policy · GitHub

[2] Confined user show policy issue: When logging into KDE from SDDM, the KDE splash screen starts but idles for around 30 seconds · Issue #1847 · fedora-selinux/selinux-policy · GitHub