Bug 1651253

I can also report the following after sudo'ing:

# yum check-update
-bash: /bin/yum: /usr/bin/python: bad interpreter: Permission denied

SELINUX_ERR:
----
time->Fri Nov 16 16:56:02 2018
type=PROCTITLE msg=audit(1542383762.139:455): proctitle="-bash"
type=PATH msg=audit(1542383762.139:455): item=0 name="/bin/yum" inode=50503023 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1542383762.139:455):  cwd="/root"
type=SYSCALL msg=audit(1542383762.139:455): arch=c000003e syscall=59 success=no exit=-13 a0=1479d20 a1=14730a0 a2=147d6f0 a3=7ffebbebf320 items=1 ppid=5453 pid=5504 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=8 comm="bash" exe="/usr/bin/bash" subj=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null)
type=SELINUX_ERR msg=audit(1542383762.139:455): op=security_compute_sid invalid_context=sysadm_u:system_r:rpm_t:s0-s0:c0.c1023 scontext=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=process


I thought that this kind of issues had been handled through BZ 1582146 but apparently not, only X11 related issues were handled.

Created attachment 1507415 [details]
Errors seen with user "staff" mapped to "staff_u"

Created attachment 1507416 [details]
Errors seen with user "sysadm" mapped to "sysadm_u"

Attached result of experiments with "staff_u" and "sysadm_u" SELinux users for following commands:
- rpm -qa
- semanage login -l
- journalctl
- yum info bash

This list is not exhaustive, just examples, probably other binaries will also fail.

User configuration:

useradd -Z staff_u staff
useradd -Z sysadm_u sysadm

sudo configuration:

staff	ALL=(ALL)	NOPASSWD: ALL
sysadm	ALL=(ALL)	NOPASSWD: ALL

I experience the issue with yum. A workaround is to run yum via python directly...

Name        : selinux-policy-targeted
Arch        : noarch
Version     : 3.13.1
Release     : 229.el7_6.6

sudo semanage user -l
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r

sudo semanage login -l
someInterestingUser staff_u s0-s0:c0.c1023 *

id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

sudo id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

sudo yum search selinux-policy
sesh: unable to execute /bin/yum: Permission denied

sudo /usr/bin/python /bin/yum search selinux-policy
(valid results)

I have this same issue from trying to assign users to sysadm_u for a confined root experience.

I think this forum posting is a related issue from CentOS that suggests it might be an upstream policy bundling issue:
https://www.centos.org/forums/viewtopic.php?t=44418

Relevant excerpt:
"My suspicion is that the real issues is the absence of the 'rpm' policy (which appears in the reference but doesn't appear to be included) OR the base policy needs changed to add the 'rpm_exec_t' to the 'sysadm_r'."

Talked with the folks on IRC, and the issue has to do with role transitions:
sesearch --role_trans | grep role_transition.*rpm_exec_t

Those role transitions automatically transition the sysadm_r and system_r roles to the system_r when accessing rpm_exec_t.

The workaround is to add system_r to your selinux user.

Raymond's work around did the trick. I feel like it is a bug but know far too little about it to actually be certain. Close enough to meet my goal of removing unconfined users from portions of our environment.

Hi Lukas,
Could you please give details why the work around proposed by Raymond is working?
I may then update the KCS until the BZ is effectively fixed.
Thanks.

I am trying to limit the number of unconfined users so I removed system_r and unconfined_r from most selinux users. This broke yum and I believe something else but I don't remember what. By adding system_r back to the roles things work as expected. This is not ideal since system_r is largely unconfined in the policy but at least it has a significant number of automatic transitions to confined types making it better than unconfined_r for my purposes.

Before applying the suggested workaround:

semange user -l 

SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles                                                       
guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
unconfined_u    user       s0         s0-s0:c0.c1023                 unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r

sudo yum search selinux-policy
sesh: unable to execute /bin/yum: Permission denied

After changing selinux role mappings:

semange user -l 

SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles                                                       
guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r system_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
unconfined_u    user       s0         s0-s0:c0.c1023                 unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r


yum functions properly without calling it via "sudo /usr/bin/python /bin/yum search selinux-policy"

To the best of my understanding, the crux of the issue is that sysadm_r does a forced transition to system_r when accessing a rpm_exec_t as enforced by the role_transition rules.
If the selinux user does not have access to the system_r role, this automatic transition fails thus denying the action. sysadm_u on default redhat only has sysadm_r attached, thus it is insufficient to act as a system administrator. First glance suggests that there's an expectation that rpm_exec_t should be accessible to sysadm_r without an implicit role transition. Since rpm package can attempt a service restart via systemctl, it may be necessary to acquire system_r to talk to systemd.

Looking at the role transitions, I'll assume that any boot time processes should require system_r to interact with them. So excluding initrc, we get the following list of forced transitions:
sesearch --role_trans | grep -v initrc
Found 416 role_transition rules:
   role_transition unconfined_r dhcpc_exec_t system_r;
   role_transition unconfined_r livecd_exec_t system_r;
   role_transition unconfined_r install_exec_t system_r;
   role_transition system_r unconfined_exec_t unconfined_r;
   role_transition unconfined_r dhcpc_helper_exec_t system_r;
   role_transition unconfined_r pki_ra_script_exec_t system_r;
   role_transition unconfined_r pki_tps_script_exec_t system_r;
   role_transition sysadm_r rpm_exec_t system_r;
   role_transition sysadm_r dhcpc_helper_exec_t system_r;
   role_transition sysadm_r pki_ra_script_exec_t system_r;
   role_transition sysadm_r pki_tps_script_exec_t system_r;
   role_transition system_r rpm_exec_t system_r;

The transition from system_r to system_r for rpm_exec_t seems redundant or possibly wrong.
The transition from sysadm_r to system_r for rpm_exec_t seems wrong, as rpm is a database not a system daemon.

The dhcpc_helper_exec_t, pki_ra_script_exec_t, and pki_tps_script_exec_t, may also have incorrect role transitions and actually need to be made accessible to the sysadm_r role directly.

This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

Hi Lukas,

Since the BZ won't be fixed, please provide a safe work around to use. In particular is adding "system_r" to "sysadm_u" and "staff_u" something safe we should recommend?

Thanks,

Renaud.

Hi All, 

Attaching workaround to run semanage commands under sysadm_u. I'll use easy example. 

## create admin Linux user and allow use sudo to this account:
# adduser admin -G wheel -Z sysadm_u

## Allow sysadm_u SELinux user to switch to secadm_r role. 
# semanage user -m -R "sysadm_r secadm_r" sysadm_u  

## Install policycoreutils-newrole package
# yum install policycoreutils-newrole -y 

## Using SELinux boolean allow sysadm to login over ssh
# setsebool -P ssh_sysadm_login=1

## login as admin
# ssh admin@localhost
Last login: Mon Apr 29 07:35:03 2019 from localhost
$ 

## execute sudo -i 
$ sudo -i 
#

# newrole -r secadm_r
#

# id -Z 
sysadm_u:secadm_r:secadm_t:s0-s0:c0.c1023

# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
admin                sysadm_u             s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

Lukas,

That workaround is redundant with the capabilities already available to sysadm_r.

The user's concerns were with direct sudo invocatio of the following:
- rpm -qa
- semanage login -l
- journalctl
- yum info bash

The sysadm_r role already has access to semanage and journalctl, no additional policy modifications required.
The secadm_r grants access to selinux policy, which is redundant with what sysadm_r already provides.

The user's desire for RPM and yum to both function is still not addressed as that requires a transition to the system_r role for the action.
The sysadm_r user has the automatic transitions, but requires the selinux user be permitted to transition to the system_r role.

For the user to use sudo to run semanage successfully, they need to specify a role for sudo to transition to. This is implicit with the -i login option, but not with a bare invocation.

Valid workarounds to address the "semanage login -l" for the issue are to configure sudoers to assign a selinux role for the user logged in, or explicitly specify the selinux role as part of the sudo invocation.
e.g.
sudo -r sysadm_r semanage login -l

or update sudoers configuration with:
staff	ALL=(ALL)	ROLE=sysadm_r NOPASSWD: ALL
sysadm	ALL=(ALL)	ROLE=sysadm_r NOPASSWD: ALL

Hi Raymond,

Thank you for proposing workarounds, in particular the sudoers configuration which makes things transparent to users.


Hi Lukas,

I would like you to reconsider this BZ. It appears that the issue is wider than just "semanage": the same happens with the following scenarios:

- staff_u user in wheel group not being able to look at log files:

  $ sudo less /var/log/messages
  /var/log/messages: Permission denied

- staff_u or sysadm_u user in wheel group not being able to restart a system service:

  $ sudo systemctl restart rsyslog
  Failed to get D-Bus connection: Operation not permitted


All this gets fixed with Raymond's proposed workaround:

  %wheel	ALL=(ALL)	ROLE=sysadm_r NOPASSWD: ALL

This also fixes issues reported in #C7

Thanks,

Renaud.

(In reply to Renaud Métrich from comment #26)
> Hi Raymond,
> 
> Thank you for proposing workarounds, in particular the sudoers configuration
> which makes things transparent to users.
> 
> 
> Hi Lukas,
> 
> I would like you to reconsider this BZ. It appears that the issue is wider
> than just "semanage": the same happens with the following scenarios:
> 
> - staff_u user in wheel group not being able to look at log files:
> 
>   $ sudo less /var/log/messages
>   /var/log/messages: Permission denied
> 
> - staff_u or sysadm_u user in wheel group not being able to restart a system
> service:
> 
>   $ sudo systemctl restart rsyslog
>   Failed to get D-Bus connection: Operation not permitted
>

This is expected, staff is unprivileged user allowed to run sudo (not command executing as different user). You need to change role to sysadm_r to do admin stuff on system. (Like you did in sudoers file or you can use newrole command.)
 
> 
> All this gets fixed with Raymond's proposed workaround:
> 
>   %wheel	ALL=(ALL)	ROLE=sysadm_r NOPASSWD: ALL
> 
> This also fixes issues reported in #C7
> 

This is correct, this config saying that if user (e.g: staff) executes sudo, there is also role change to sysadm_r (from staff_r)

> Thanks,
> 
> Renaud.

I don't see any issue here.

Closing.

(In reply to Lukas Vrabec from comment #27)
> - sysadm_u user in wheel group not being able to restart a system
> service:
> 
>   $ sudo systemctl restart rsyslog
>   Failed to get D-Bus connection: Operation not permitted
> 
> This is expected, staff is unprivileged user allowed to run sudo (not
> command executing as different user). You need to change role to sysadm_r to
> do admin stuff on system. (Like you did in sudoers file or you can use
> newrole command.)

This one should work when user is mapped to sysadm_u, there should be no need to change role to sysadm_r.

Renaud, 

I don't understand. sysadm_r is default role for sysadm_u user. There is no need to change role to sysadm_r. 

Lukas.

This is the issue: without changing role to sysadm_r explicitly, "sudo <command>" from sysadm_u fails.

Reproducer:

# useradd -G wheel -Z sysadm_u mysysadm
# echo mysysadm | passwd --stdin mysysadm


$ ssh mysysadm@vm-selinux7

$ id
uid=1002(mysysadm) gid=1002(mysysadm) groups=1002(mysysadm),10(wheel) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

$ sudo id
uid=0(root) gid=0(root) groups=0(root) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

--> OK "sysadm_r" role

$ sudo semanage login -l
Traceback (most recent call last):
  File "/sbin/semanage", line 32, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject/__init__.py", line 36, in <module>
    import sepolicy
  File "/usr/lib64/python2.7/site-packages/sepolicy/__init__.py", line 930, in <module>
    raise e
ValueError: No SELinux Policy installed

--> FAIL

$ sudo systemctl restart rsyslog
Failed to get D-Bus connection: Operation not permitted

--> FAIL

$ sudo -r sysadm_r semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service
...

--> OK (explicitly changing role from sysadm_r to sysadm_r ...)

$ sudo -r sysadm_r systemctl restart rsyslog

--> OK (explicitly changing role from sysadm_r to sysadm_r ...)

commit d5778b7672b2e65747d2bb8d59a25e218f8f1a23 (HEAD -> rhel7.8-base)
Author: Lukas Vrabec <lvrabec>
Date:   Mon Jul 22 17:33:45 2019 +0200

    Allow sysadm_sudo_t to use SELinux tooling.
    Resolves: rhbz#1727341

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1007

This issue should not be resolved. I have the wheel group assigned to staff_u and I get errors when trying to sudo. It will sudo su -, but I get -bash: /root/.bash_profile: Permission denied. If I try sudo semanage login -l, it returns: ValueError: No SELInux Policy installed.
I'm running Red Hat 7.9 and this is still an issue. Pretty much the same as Bug 1688887. It was also marked closed and it is clearly not fixed.

Hi John,

I think there is confusion here: the issue was with user being sysadm_u at time of *sudo*.

Here you state your user is mapped to staff_u, so it's expected to fail when sudo'ing, *except* if you implement (automatic or not) role change:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ sudo -r sysadm_r su -

or

$ sudo -r sysadm_r semanage login -l
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This is because even if root, "staff_t" type cannot execute the above commands (with "su -", you remain "staff_t", hence cannot access /root/.bash_profile).