Whether to use selinux user sysadm_u

Ask Fedora
1

Hello,

I tried logging onto my system with the staff_u user and it wasn’t usable because of all the AVC denials that wouldn’t go away, and I didnt want to add them because I didnt fully know what it wanted to let me allow.

Which brings me to the sysadm_ u user who I have created and I set the boolean for it to be able to log in. My question is when I logged on it only had just a few AVC denials compared to the laundry list of AVC denials for the staff_u user. Which user would you recommend I use for my case?

I don’t want to use the unconfined_u user because I want to write selinux policies from scratch for my own apps and that doesn’t work when unconfined_u lets you run pretty much anything already.

2

I messed with a few policies for webserver daemons, but never heard of sysadm_u; it sounds elevated and I wouldn’t think it’d be necessary to use (webserver stuff likely wouldn’t need it, but maybe direct-GPU compute stuff)

3

You might check the tag of the topic :classic_smiley: It’s more or less dedicated to the confined user profiles of SELinux (sysadm_u, staff_u, user_u) :slight_smile:

I cannot tell. On one hand, your descriptions are quite generic for such specific questions. On the other hand, that’s a decision only you can make (and that also depends on your apps’ use cases and environments): as you already found out, sysadm_u allows much more by default, but is still more active within a user account compared to unconfined_u.

By default, there should be no denials if everything is set properly. If there is a denial by default, it is worth a bug report. If denials occur after you made any change, then you might need to adjust your policy.

sysadm_u is definitely not supposed to be used “by default” (as the name indicates), but it still increases security within the account compared to unconfined_u, so it would be still an increase in security. That said, for users, sysadm_u is the only thing that I assume can be developed to the point normal users can use confinement at all and it is still a big increase of process/data isolation compared to unconfined_u → the user_u/staff_u stuff is too restrictive for Fedora-type users for several reasons.

However, when you want to make great policies and optimize them to the level of working in a confined environment, well, then you might want to test them against user_u rather than just sysadm_u. The tools we have that have standardized tests with confinement always test against user_u → if your policy works against user_u, the policy is either great (or too little restrictive:). That said (again), keep in mind that there are actions that are simply not intended for user_u (and staff_u), so depending on what your apps do or need, they might not work at all that way. That’s a reason why I think user_u will never be useful for Fedora-type users (issues start with not allowing sudo/su in user_u).

In short, I think we cannot be of much help in this very case :frowning: If you can make it work with user_u, that is the best testing environment for your policies, but you need to find out if your apps’ needs can be satisfied with user_u at all.

All that said, I much appreciate developers/maintainers who want to make their tools’ policies bulletproof :classic_smiley: Too many see this as a burden rather than as an opportunity for opmitizing their product.

1 Like
4

Yeah, I don’t want to use user_u because like you said it is too restrictive, and I can’t use sudo with or load/write policies with it. Regarding the sysadm_u if I were to still use it would you recommend I add additional roles with it since the only role associated with sysadm_u is sysadm_r.

Like I said my case is I’m trying to write policies from scratch, and not just for apps but simple shell scripts, but I can’t test them out if everything pretty much is allowed under the unconfined_u user.

5

staff_u cannot su, but it can sudo.

The “official suggestion” is always to avoid sysadm_u but work with staff_u and only get sysadm_r when necessary. If you get permanently sysadm_u (which for many users might be easier to work with and still more secure than most distributions’ default unconfined_u even if the name make us “feel” different due to the “sysadm” in the name), then you will have sysadm_r permanently. Normally further roles should not be necessary.

But again, I do not know your use cases nor intentions. So I cannot answer the underlying questions for you: the more restrictions you take, the more secure it is from a solely technical security perspective, and the more powers you need, the less restrictive profiles you have to choose. With the examples you mentioned in mind:
user_u → no sudo, no su
staff_u → sudo yes, but no su
sysadm_u → both yes

sysadm_r can be linked to staff_u as it can be linked to sudo, so that a staff_u gets sysadm_r through sudo (see a lot of upstream documentation and earlier topics of the selinux-confined-users tag).

There are more things to explore, which you might want to review in the documentations: in the end, you can play with it, and see what fits you best. Easiest way: check out what works and what cannot work at all based on allowed/prohibited functions (which you can adjust only to a limited extent), and then choose of the working variants the mots secure/restrictive one.

6

This is supposed to be true, but it is not. I have a user_t profile, and it can indeed access sudo commands.

Screenshot From 2026-02-01 18-55-38
Screenshot From 2026-02-01 18-55-383072×1664 188 KB

I believe ATM, user_t can run normally from a terminal. When you use it with a GUI, then you will get all the AVC’s.

7

So I did some more testing and I should have read the AVC denials more clearly. This is for the staff_u, but I get the same denials with the sysadm_u when I first login.

It’s bwrap causing the issues which wasn’t a thing last time I used Fedora 5+ years ago.

avc: denied {mounton} comm=“bwrap” path=“/”
scontext=staff_u:staff_r:staff_t
tcontext=system_u:object_r:root_t
tclass=dir

What should I do?

8

Very interesting I’ll test this out tomorrow.

9

I believe ATM, user_t can run normally from a terminal. When you use it with a GUI, then you will get all the AVC’s.

I can neither of the two with user_u on a default fedora, which is as intended. Did u made modifications on the test system? I saw that is possible to achieve with modifications, although never tested myself.

10

As Chris already wrote, for most cases it is recommended to have the staff_u SELinux user assigned to Linux user and allow them to get to a different role for particular commands or “sudo -i”. Some examples can be found in

Certainly also policy for user_t can be modified to allow them additional rules (like using sudo) which are not allowed by default.

11

@darkmatter64
  To clarify my previous statement, I assumed you already had the selinux mode in a permissive state to read the AVC’s.

  Just in case you didn’t know, placing the policy in permissive mode almost allows anything to proceed as if selinux wasn’t enforcing the policy, but logs AVC’s as it was in enforcing.

 I personally keep my user_t type and NOT the whole system in a constant permissive mode to test various custom policy like you are trying to do, without risking the whole operating system’s security.

  • sudo semanage permissive --add user_t

BTW, @py0xc3 and @zpytela are correct that by default the policy blocks access to both sudo and su for certain roles, and also, that modifications allow you to proceed around the constraints.

12

I get that but when you first map your linux user to the SElinux user staff_u and when you login with that new user you are bombarded with non-stop AVC denials that keep flashing which is annoying. Like I said I used the staff_u a few years ago and there wasn’t this problem before.

13

I’ll look into that.

14

Not fully sure if I get the underlying issue:

If you made adjustments yourself, and then had the AVC denials, then you must adjust your policies: staff_u is much more radical than most other profiles, and therefore is less forgiving if something is not perfect :classic_smiley: The alternative is of course to reduce your expectations/QA and go to a more forgiving profile.

If you have not made changes yet, but get AVC denials on a default Fedora, which has been cusomized only with installing additional packages from Fedora repositories, then this would be an issue in our policies: if that is the case, please create a “dedicated boot” for analysis: boot your system, login, do only do the action(s) that cause AVC denials and note the exact time you conduct these action(s) incl. seconds (IF there are a specific action(s) involved in provoking the denials), and then directly provide the output of the following 5 commands to give us the AVC denials and the environment:

uname -r
cat /proc/sys/kernel/tainted
sudo dnf repolist
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
sudo journalctl --no-hostname --boot=0

The last command can contain data like UUIDs, IPs, MAC addresses: feel free to anonymize them if you consider them private.