Bug 2031068

This is how I understand the bz report: When a Linux user in the staff_r role becomes a Linux system administrator, but the role still is a role of a confined user and not a confined administrator, the user cannot access the postgres database home directory.

It does not seem to be a bug in selinux-policy. When the role changes to sysadm_r or dbadm_r on execution of the sudo command or when newrole with proper settings is used, the access is allowed. I can't see a reason for a confined user to access the db root or manage the database. All administration tasks should be done in any of SELinux administrator roles.

Closing this bz NOTABUG as a result.

Hi Zdenek,

Your assumption is incorrect, sorry the description was not clear enough apparently.
The issue happens with staff_u (which is somehow expected) but also sysadm_u, see below:

#============= sysadm_su_t ==============
allow sysadm_su_t postgresql_db_t:dir search;

#============= sysadm_sudo_t ==============
allow sysadm_sudo_t postgresql_db_t:dir search;


The attached KCS https://access.redhat.com/solutions/6582811 shows workarounds, all of them force becoming unconfined_u which is definitely not recommended.

I can confirm switching to dbadm_r role doesn't work on either RHEL7 or RHEL8, this creates AVCs:


1. Adding "dbadm_r" role to existing "sysadm_u" user:

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  # semanage user -m -R "sysadm_r dbadm_r" sysadm_u
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

2. Login in as "sysadm_u" and trying to sudo:

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  [sysadm@vm-postgresql7 ~]$ id -Z
  sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
  [sysadm@vm-postgresql7 ~]$ sudo -t dbadm_t -r dbadm_r -u postgres -i
  sudo: unable to execute /bin/bash: Permission denied
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

AVCs in Permissive:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
time->Thu Jun  9 11:31:42 2022
type=PROCTITLE msg=audit(1654767102.223:680): proctitle=7375646F002D7400646261646D5F74002D7200646261646D5F72002D7500706F737467726573002D69
type=SYSCALL msg=audit(1654767102.223:680): arch=c000003e syscall=59 success=no exit=-13 a0=7f23cd756765 a1=55806072c310 a2=558060740eb0 a3=633a30732d30733a items=0 ppid=10601 pid=10603 auid=1001 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 tty=pts0 ses=15 comm="sudo" exe="/usr/bin/sudo" subj=sysadm_u:sysadm_r:sysadm_sudo_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1654767102.223:680): avc:  denied  { transition } for  pid=10603 comm="sudo" path="/usr/libexec/sudo/sesh" dev="dm-0" ino=346445 scontext=sysadm_u:sysadm_r:sysadm_sudo_t:s0-s0:c0.c1023 tcontext=sysadm_u:dbadm_r:dbadm_t:s0-s0:c0.c1023 tclass=process permissive=0
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Renaud,

Please follow the Procedure in the product documentation to setup sudo:
https://access.redhat.com/documentation/en-us/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

just with sysadm substituted for dbadm. After the required semanage-user setting, e. g.

# semanage user -m -R "sysadm_r dbadm_r staff_r unconfined_r" staff_u

the user can get a shell or execute a command:
$ id
uid=1001(example) gid=1001(example) groups=1001(example),10(wheel) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
$ sudo /bin/id
uid=0(root) gid=0(root) groups=0(root) context=staff_u:dbadm_r:dbadm_t:s0-s0:c0.c1023
$ sudo -i
-bash: /root/.bash_profile: Permission denied
# id
uid=0(root) gid=0(root) groups=0(root) context=staff_u:dbadm_r:dbadm_t:s0-s0:c0.c1023

The sysadm role was designed to use only with administrative Linux account. It is also called confined administrator, while staff is a confined user.

I've just verified the documented scenario works in both RHEL 8 and 9 and also for both dbadm_r and sysadm_r roles, so closing the bz, but feel free to reach out to our team again in case of an outstanding issue.