Bug 1922450

Summary:	staff_u users can utilize newrole, resulting in ability to access su directly
Product:	Red Hat Enterprise Linux 8	Reporter:	Ryan Mullett <rmullett>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	high
Version:	8.3	CC:	jafiala, lagordon, lvrabec, mmalik, plautrba, ssekidde, wdh, zpytela
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.0	Flags:	pm-rhel: mirror+
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-03-25 16:42:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1778780

Description Ryan Mullett 2021-01-29 18:35:04 UTC

Description of problem:
According to documentation here:

Using SELinux Red Hat Enterprise Linux 8 | Red Hat Customer Portal
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/using_selinux/index#managing-confined-and-unconfined-users_using-selinux

Users with the staff_u role should only be able to access sudo, but should not have access to su. Because staff_u can utilize the newrole command to change to sysadm_r, they can still access su

Version-Release number of selected component (if applicable):
policycoreutils-newrole-2.9-9.el8.x86_64
selinux-policy-3.14.3-54.el8.noarch

How reproducible:
Always

Steps to Reproduce:

1. useradd -Z staff_u someuser -G wheel
2. ssh someuser.com
3. newrole -r sysadm_r
4. id -Z
5. su - will be successful (according to docs this should fail)

Actual results:
su - is successful

Expected results:
According to documentation staff_u should not be able to utilize su, and should be limited to sudo.

Additional info:
In the default configuration, staff_u is listed as having access to staff_r, sysadm_r, and unconfined_r. I expect that this may be expected behavior, and that the issue lies on the documentation side, if so I believe some clarification is needed regarding what the actual limitations of staff_u are.

[root@localhost ~]# semanage user -l

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r

Comment 2 Zdenek Pytela 2021-02-08 21:28:09 UTC

There are 2 ways for staff_u users how to get the sysadm_r role: using sudo or newrole. The scenario described in the bz is a correct way, after the change sysadm_r role should be allowed run su. This is not a bug.

It looks it is the documentation which needs improving as there is only one line containing staff_u together with staff_r and staff_t which does not cover changing users roles. Thank you for reporting it.

Also note the user part of context cannot be changed.

Comment 5 W. de Heiden 2021-02-17 07:47:33 UTC

"There are 2 ways for staff_u users how to get the sysadm_r role: using sudo or newrole." Well, there is a third option; I can login using userx/sysadm_r.com. (when the boolean ssh_sysadm_login is enabled)

Comment 7 Zdenek Pytela 2021-03-25 16:42:57 UTC

The problem reported in this bz is not a selinux-policy bug.
The documentation ambiguity will eventually be addressed by distinguishing between users and roles.