1

New security policy mandates that system administrators on RHEL systems must be mapped to either sysadm_U or staff_u role and 'normal' users must be mapped to user_u roles. Previous to this we utilized the out-of-the-box configuration with all users having the unconfined_u.

Upon running a small test with mapping a system administrator group to the sysadm_u role I found that these users were initially unable to log in via SSH. After digging into the SELinux policy source I found that there was a boolean, ssh_sysadm_login, that needed to be set to allow this function.

I also tried mapping this same group to the staff_u role. This role happened to be able to SSH just fine but, by coincidence, I discovered that they were unable to perform SSH port forwarding operations. Again, I was able to find the boolean, user_tcp_server which fixed this.

In any case these two immediate effects on common (critical) administrator functions has me concerned what other "gotchas" I might expect to run in to when rolling out this change. It was noted that this change could impact deployed applications which could make the scope of this question very broad. Therefore, let's focus the answers on the impacts one would expect to see on a base OS install affecting core functionality (e.g. the aforementioned SSH issues).

Improve this question
3
  • While it's an interesting and useful question, I feel it's too broad for stack exchange. There's no right answer, and could start encompassing a huge variety of apps.
    – Jeff Schaller ♦
    Jun 10, 2017 at 13:37
  • I think there are a finite (small) number of items one would generally run into. There should be a generalization of the ways it might impact apps as a group but not any app specifically.
    – LJKims
    Jun 10, 2017 at 13:50
  • Is this better after I scoped it down? I do think the answer would be useful to many.
    – LJKims
    Jun 10, 2017 at 13:53

1 Answer 1

Reset to default
0

If anyone has questions on this since these policies were updated:

staff_u should be assigned to users who SSH into the box, including administrators. You assign staff_u because by default sysadm_u is not able to SSH to the machine because of the SELinux boolean ssh_sysadm_login.

In your /etc/sudoers, you need to add the following to make it so that users who use sudo/su will get the sysadm_u user and sysadm_r role when elevating:

%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

The most recent of these (and related) guidelines are in the V3R5 RHEL 7 STIG, released 27 OCT 2021, vulnerability IDs V-250312, V-250313, V-250314, and V-204444

As for "gotchas", if you have a machine that was previously running without SELinux user mappings, make sure to restart services or be aware that issues will probably arise. staff_u not being able to port forward is an example of that, and this will vary from organization to organization. setroubleshoot-server will be your friend to customize these policies to your needs. I also recommend the Gentoo wiki's SELinux Tutorials, as they are some of the best I have read so far.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.