Bug 1965251
| Summary: | Confined sysadm users cannot execute sosreport command | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> | |
| Component: | selinux-policy | Assignee: | Patrik Koncity <pkoncity> | |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 8.4 | CC: | lvrabec, miturria, mmalik, pkoncity, plautrba, ssekidde, wdh, zpytela | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | 8.6 | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.14.3-84.el8 | Doc Type: | Bug Fix | |
| Doc Text: |
If this bug requires documentation, please select an appropriate Doc Type value.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2014606 (view as bug list) | Environment: | ||
| Last Closed: | 2022-05-10 15:14:58 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, 2014606 | |||
There are a lot of commands that are unavailable to the sysadm_u user. For example: m$ id -Z sysadm_u:sysadm_r:sysadm_t:s0 $ sudo gdisk /dev/sdb GPT fdisk (gdisk) version 1.0.3 Problem opening /dev/sdb for reading! Error is 13. You must run this program as root or use sudo! The only way to manipulate block devices appears to be as unconfined_u and as mentioned above, the transition via sudo is impossible because of missing policy. Hi Markus, Since executing "sudo gdisk" is different than "sudo -i" then "gdisk" (there are bugs around this as well), please try the latter and report here: $ sudo -i # gdisk /dev/sdb Hi Renaud - I get the same results if the user is a sysadm_u:
$ id -Z
sysadm_u:sysadm_r:sysadm_t:s0
$ sudo -i
$ gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
Problem opening /dev/sda for reading! Error is 13.
You must run this program as root or use sudo!
I cannot transition to unconfined_r because the transition is not defined:
# sudo -i -r unconfined_r
sudo: sysadm_u:unconfined_r:unconfined_t:s0 is not a valid context
Counterintuitively, I can grant staff_u the right to transition to uconfined_u:
$ semanage user -m -R "staff_r sysadm_r system_r unconfined_r" staff_u
$ id -Z
staff_u:staff_r:staff_t:s0
$ sudo id -Z
staff_u:staff_r:staff_t:s0
jruser:com1922 ~> $ sudo -r unconfined_r id -Z
staff_u:unconfined_r:unconfined_t:s0
$ sudo -r unconfined_r gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
[...]
I cannot do the same with the sysadm_u user:
$ semanage user -m -R "staff_r sysadm_r system_r unconfined_r" sysadm_u
$ id -Z
sysadm_u:sysadm_r:sysadm_t:s0
% $ sudo -r unconfined_r -i
sudo: unable to execute /bin/zsh: Permission denied
Hi Markus, Yes you cannot move to unconfined_r role for sysadm_u because of BZ #1965265 Renaud - that makes sense. I'm following that bug. I then assume these are really the same problem. I hope this is fixed soon. The RHEL Security Technical Implementation Guide (albeit for RHEL 7) requires that system administrators run as sysadm_u or staff_u. https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2020-09-03/finding/V-204444 "All administrators must be mapped to the "sysadm_u", "staff_u", or an appropriately tailored confined role as defined by the organization. All authorized non-administrative users must be mapped to the "user_u" role." Unfortunately staff_u is also suffering some bugs (on systems running Xorg rather than Wayland). I submitted a bug for this. BZ #1959173 Hi Renaud, did you try the sosreport with staff_u which has role transition to unconfined_r? I ask because I'm not sure if really depends only on switch to unconfined_r role while sudo'ing. Thank you, Patrik Yes, it doesn't work either. Note that it's not only sosreport issue, most admin commands fail similarly. Hence being able to run as unconfined_r is a solution, but still needs to be considered as a workaround (customers expect systems to be work properly even with fully confined users). PR:https://github.com/fedora-selinux/selinux-policy/pull/795 PR: https://github.com/fedora-selinux/selinux-policy/pull/796 Also need's to be backported dontauditing of /proc/1/environ reading. Commits to backport: commit 8d50092eec6f18aea35923d27330f6319a09087d (HEAD -> rawhide, upstream/rawhide, origin/rawhide, commit 3f32491846b3cdbdde54c2021f1f945618124db6 commit d61e73df309765628b5819cca855d66e2efd8985 commit f1f3b3afb58156e5795a58ac694360c4db6727a7 commit 207078d706e974e3fe04eed615a96a1ed3d50705 commit 73a40f067bc81f9daccbba8fa957f0f3b1e50826 commit 00945ef38279155373eff1bf5d5f90e714691dae The denials as reported seem to be addressed, but other denials can pop up in different sos configurations, so retargetting to RHEL 8.6. A customer came with another command which doesn't work while being `sysadm_t`: $ sudo /usr/sbin/postsuper See also KCS https://access.redhat.com/solutions/6324001 for related issues. Two more commits to backport:
commit 78a05d318a2c3eb59b66561b51b3483ea7074738 (HEAD -> rawhide, upstream/rawhide)
Author: Patrik Koncity <pkoncity>
Date: Wed Sep 22 16:30:42 2021 +0200
Allow proper function sosreport via iotop
Sosreport in sysadm role run iotop plugin
in iotop_t domain. Allow iotop handling with
netlink generic socket and unix dgram socket.
Also allow execute ldconfig_exec_t binary
in iotop_t domain.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1965251
commit d3b8b6c4df172de698a8db938001ed6c0225d1be
Author: Patrik Koncity <pkoncity>
Date: Wed Sep 22 15:31:21 2021 +0200
Allow proper function sosreport in sysadmin role
Allow sysadm_t domain to read and write chr_files
in autofs_device_t domain.
Allow sysadm_t domain to read and write chr_files
in lvm_control_t domain.
Allow sysadm_t domain to manage dirs and files
in configfs_t domain.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1965251
Existing commit to backport:
commit e62fb4dadf53079955379ec3bc4164cfc8f66e4a
Author: Zdenek Pytela <zpytela>
Date: Thu May 6 21:25:57 2021 +0200
Allow sysadm_t dbus chat with tuned
and a bunch of new ones sent for review:
https://github.com/fedora-selinux/selinux-policy/pull/949
*** Bug 2025925 has been marked as a duplicate of this bug. *** *** Bug 2003153 has been marked as a duplicate of this bug. *** 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 (selinux-policy bug fix and enhancement update), 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-2022:1995 |
Description of problem: We start having customers trying to get rid off the root account completely and have their users confined. Unfortunately, not much works when a sysadm user sudo'es to root to collect a sosreport for example: 1. We see AVCs -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- #============= sysadm_t ============== allow sysadm_t container_ro_file_t:dir mounton; allow sysadm_t device_t:chr_file read; allow sysadm_t hi_reserved_port_t:tcp_socket name_bind; allow sysadm_t lvm_control_t:chr_file { read write }; allow sysadm_t scsi_generic_device_t:chr_file { read write }; allow sysadm_t sysadm_sudo_t:key view; allow sysadm_t sysctl_vm_t:file relabelto; allow sysadm_t tmp_t:chr_file create; allow sysadm_t var_run_t:chr_file create; allow sysadm_t virt_var_run_t:sock_file unlink; -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 2. sosreport command dies because it cannot write the archive -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Permission denied while finalizing archive /var/tmp/sos.kydrcitq/sosreport-vm-confined83-2021-05-27-yyhcwcy Creating archive tarball failed. Traceback (most recent call last): File "/sbin/sosreport", line 33, in <module> sos.execute() File "/usr/lib/python3.6/site-packages/sos/__init__.py", line 185, in execute self._component.execute() File "/usr/lib/python3.6/site-packages/sos/report/__init__.py", line 1350, in execute return self.final_work() File "/usr/lib/python3.6/site-packages/sos/report/__init__.py", line 1263, in final_work archivestat, map_file=map_file) UnboundLocalError: local variable 'archivestat' referenced before assignment -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Version-Release number of selected component (if applicable): selinux-policy-targeted-3.14.3-67.el8.noarch How reproducible: Always Steps to Reproduce: 1. Create a confined user mapped to sysadm_u # useradd -Z sysadm_u -G wheel sysadm 2. Switch to the user, sudo and execute sosreport $ id -Z sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 $ sudo -i # sosreport ... Actual results: AVCs + sosreport dies on Permission denied Expected results: No AVC + sosreport succeeds Additional info: The only possibility I see here is to switch to unconfined_r role while sudo'ing, but this even doesn't work for sysadm_u (role transition is missing in the policy), but staff_u can, which is non-sense.