I’m having a fundamental issue with the security architecture implementation of SELinux for confined users.
Some basic things I need to run as a user end up requiring sudo access but the lowest security SELinux user with sudo is basically almost a sysadmin.
So, there needs to be clever security solutions to this and I’m seeing none. I can think up solid security solutions but they involve writing an OS from scratch almost. Am I missing something?
Can you provide some examples of the “basic things” that require elevated privileges?
Just take mount. It’s easy to root someone with mount apparently so you have to sudo it. But there are innocuous things contained in the realm of user space that would just need an easy sandbox type of mount to play with without having to work around it and preconfigure the system. If mount is flawed from the security standpoint then there’s something wrong already at the foundation.
That raises a bigger question of what a “user” is and what a “sysadmin” is. A good example I have given when i have been asked this in the past is access to a storage server. I (personally) dont want “users” to be able to mount random devices or network drives, I want users to login store files maybe have some scripts to help them but i dont want them touching the system at large. Sysadmins would be the only ones who make changes to the system.
Another example would be systems you deploy in a computer lab with students who may or may not try and malicious tricks, you want to try and prevent any malicious programs or scripts from breaking containment and wrecking havoc on your system(s).
The key take away is define what a user is and a sysadmin is for your use cases
Another use case is a big machine with resources beyond the capacity machines provided to users (so they can read memos from HQ and fill out their monthly reports). Such system require measures to limit access according to a user’s role (e.g., who can view certain data, add new data, or use certain software capabilities).
Yes, primarily two things:
1)
Beyond user_u, you have staff_u, which is allowed to do sudo but not su and thus makes in most cases more sense currently in Fedora because the average use cases for Fedora and the security/privilege architecture of Fedora as of today differ to those of user_u. user_u is more intended for use cases where there are non-trustworthy users and thus, the admin is separated from users. If you need to do unrestricted mount operations with an account, this account is not a user_u use case. However, even without a separated admin, you can split your account yourself to restrict untrusted processes: one account to do “daily stuff” like browsing, emailing and such (user_u), and another account to do sudo stuff (staff_u or sysadm_u). At the best, sudo operations are exceptions and not “average operations” in an architecture.
Be aware that users can mount on the user level (e.g., when you use your GUI to mount a USB device or so → this device ends up at /run/media/<username>/*) but these mount operations are much more restricted than for other users. This is part of the default security architecture of Fedora that restricts risks rising from mounts to the user account. Yet, I experienced that at least on KDE this does not work properly at the moment because even if I can mount as user, the related path /run/media/<username>/* are not labelled properly and thus can be mounted by users but need often a sysadm to read/write. So the mount is useless. This is one of two further issues for which I will collect the data to create another ticket on the repo but I have not had the time so far. Feel free to be faster than me 
I do not know how it is with GNOME (feel free to let us know if you tested it already)
2)
SELinux is not just about users but also about roles: sysadm is intended to be primarily used as role and thus shall not even have the need to use the capability to use x (graphical interfaces) → you provoke the role when necessary from an staff_u account:
You can thus combine the staff_u user with the sysadm_r role (sysadm_r , not sysadm_u) at the time when it is necessary. This is done through sudo: once you do sudo in a terminal, everything that occurs through sudo will be done as sysadm_r while everything else remains opened/executed with the much more restricted staff_u. Especially if you need custom mount operations , this might be a good solution for you (once you set this up, it happens automatically when you do sudo). Check out this for more: https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/html/using_selinux/managing-confined-and-unconfined-users_using-selinux#confining-an-administrator-using-sudo-and-the-sysadm_r-role_managing-confined-and-unconfined-users
Additional note
Be aware that from a technical perspective, SELinux can only increase security: it cannot add any privileges but adds another layer of security with its own privileges: everything is allowed only if every layer allows it → if the “traditional” / “default” layers disallow, sysadm_u will NEVER change that. Normally, SELinux (and also other mandatory access controls) enforce “around the user account” and not within (this is the default unconfined_u). Within an account, you normally have only the normal privileges. So sysadm_u does not add any sysadm privileges but only adds restrictions when compared to the defaults. In the main topic, I mentioned some examples about the massive security that it added just by using sysadm_u.
At the moment, I tend to say that sysadm_u is the only possibility to achieve a smooth untroubled graphical user experience while still adding a strong security advantage → everything below sysadm_u makes it necessary to keep in touch with the terminal, and some operations are not possible at the moment in a graphical experience. My goal would be to enable also user_u and staff_u at some point, but at the moment, you will experiencing issues. That’s what we work on 
5 Likes
But I want to be user_u for security purpuses and only need occasional sudo for simple things like mounting or launching an nspawn container.
There’s a distinction that I am not seeing made. There are user_u’s who are users other than you who you really want to be restricted because it’s not you and might potentially be attackers. Then there are user_u’s who are basically you who is a sysadmin self but who wants to run things in a very restricted context by default but needs occasional elevation for basic things that would be dangerous but not for this specific user_u because you are not going to attack yourself (hopefully? - unless you are a security researcher but that’s beyond the scope of this). And staff_u may not be it for these user_u’s who are sysadmins themselves wanting a secure user confinement.
A clear answer might start with tackling this argument: from a user account perspective, your argument is false. It’s even the opposite: most attacks take place from the user’s own account. But it’s (usually) not the user’s human inputs, but issues in or among processes, and inputs that come from, e.g., the Internet or any network that exploit processes. So, this is not only to protect the system from user inputs, but also to protect it from inputs, e.g., from the Internet that exploit types of vulnerabilities in processes.
An illustrative but today rather unlikely example is that a malicious link enables an attacker to take over the browser, and from the browser, the user account, and then the attacker might try to escalate their privileges to root.
Today, this is very unlikely to happen and modern security architectures heavily mitigate this, even without an additional mandatory access control that controls within the account. But even if this attack would successfully occur, the Firefox bug I found with the confined user account has shown that any try to get beyond Firefox’s own processes (even within the same account) will be blocked by SELinux and thus confines Firefox within its own processes unless the actual user has itself provoked the action - even when the account is just sysadm_u and not user_u (but in fact, Firefox and the kernel are good friends and they manage to even isolate Firefox’s individual tabs very well from each other → attacks that “leave” the browser processes due to malicious links/websites are thus unlikely - but it remains illustrative).
I hope that adds some clarity: the considered risks are not just the users at the keyboard and their immediate keyboard inputs.
sudo means super user’s doing. By definition this is the opposite of the user_u. Also, be aware that the major distinction between user_u and staff_u is sudo. So, if you want user_u with sudo, the answer is staff_u. I say “major distinction” because I have not the whole comparison of their rule sets/profiles in mind and do not want to say something wrong, but the capability for sudo is indeed the only difference I know between user_u and staff_u. Beyond sudo, staff_u is very restrictive (this is the reason why it still causes issues in some of Fedora’s desktop environments).
The other alternative is to use two different accounts: one for using sudo, one for operations without.
I do not see the need for more profiles, but we have to work to get all graphical user interfaces of Fedora aligned with those existing.
By the way, you can add additional security by restricting the sudo operations a given user is allowed to do.
1 Like
That’s a fair suggestion. I still believe there’s a fundamental issue with core Linux architecture - i.e. mount is inherently an unsafe operation in its entirety when it shouldn’t be.
I’ve been actually concerned with the security of giving sysadmin_u to graphical accounts (using the related GUI-boolean (xdm_sysadm_login). There’s no way to achieve lower confinement for graphical accounts and isn’t that a major vulnerability rooted in Linux’ design limitations?
Indeed, this is why user’s are limited to the /run/media/<username>/* mounts as done by the GUIs. Everything else is allowed only to sudo/root, and sudo can also contain some restrictions.
And thus, you have to be aware that the capability for sudo already needs a lot of trust in the very user account. If you want to exclude administrative/dangerous stuff from GUI as far as possible (which are indeed more vulnerable than the non-GUI TTY terminals), you might choose to use sudo only in the TTY, and thus, it might be fine to use another user account for that because you have to separately log into the TTY anyway. Indeed, the terminals within the desktop environments (e.g., qterminal), are not “fully isolated” or so from the desktop. However, even sysadm_u already enforces very strong isolations of the processes, and capturing any desktop terminal input/output, even from the same account, is hard to achieve if any type of confinement is enabled.
That said, be aware that any user confinement is currently only an additional security layer. There is already a security architecture without that, and it can ensure a lot of security of the user account. However, since most users focus on their user experience without sophisticated technical understanding, enabling confinement within user accounts can be a problem in many if not most cases. Thus, the focus is to keep the account safe and ensure that confinement within the account is not necessary. Attractive processes like Firefox have an additional security layer through SECCOMP that even isolates individual tabs “before they touch” the user account. It is like the Firefox process asks the kernel “hey, can you use your super powers to isolate my tabs?” while Firefox remains a normal user process with related restrictions.
When it comes to software, e.g., Fedora assumes and suggests that users use only supported repositories to get software to avoid malicious software to be installed and executed anywhere. If you comply to such assumptions, it is already very unlikely that a process that is started is or becomes malicious. Yet, everything on the desktop environment is somehow connected, and thus contains some risks (one of the reasons why I want to make Fedora “fully confineable”). The highest security here is to isolate accounts, and if I got your reasoning right, you should be at least as careful with providing a graphical user interface with the capability to use sudo as with the capability to be sysadm_u. I tend to even assume that the sudo capability is more dangerous than sysadm_u, especially if the sudo does not contain further restrictions in the sudoers file → As I said earlier, sysadm_u only adds restrictions compared to the default state and it cannot undermine other security layers, but sudo can lead to full power and undermine everything.
Off my mind, I am quite sure that this boolean can be disabled when you use a staff_u account that gets only the role of sysadm_r through sudo even when you use the sudo/sysadm_r within a desktop environment (thus, within a desktop terminal such as qterminal or so). Obviously, using sudo for graphical stuff won’t work.
3 Likes
A post was split to a new topic: Problems when using SELinux confined user accounts with staff_u on Fedora