This bug was initially created as a copy of Bug #1840851 I am copying this bug because: Also applies to RHEL8 apparently, as reported by a customer. Description of problem: Secure_mode boolean should prevent confined users from transitioning to sysadm domain or switch to the root user (switch to privileged role). Description of the secure_mode boolean: if secure mode is enabled, then newrole can only transition to unprivileged users But between unprivileged users is also declared unconfined user: $ seinfo - xaunpriv_userdomain Type Attributes : 1 attribute unpri v_user domain ; guest_t staff_t staff_wine_t unconfined_t user_t user_wine_t xguest_t When secure_mode boolean is enabled, user staff_u cannot switch to sysadm domain, but they can switch to unconfined domain, and do privileged(admin) operations. This transition operation should NOT be allowed when secure_mode boolean is enabled: staff_u:staff_r 🡒 staff_u:unconfined_r Version-Release number of selected component (if applicable): selinux-policy-3.14.5-31.fc32.noarch How reproducible: Always Steps to Reproduce: 1. Enable secure_mode boolean 2. Login as SELinux user staff_u 3. Switch with newrole to unconfined_r Actual results: SELinux user staff can switch to unconfined domain Expected results: SELinux user staff cannot switch to unconfined domain Additional info: Proposed fix: remove unconfined_t from unpriv_user_domain.
Yes of course, Zdenek we need add this PR to RHEL-8. PR: https://github.com/fedora-selinux/selinux-policy/pull/458/commits/f01a2ea9d11def18b671a5f76a52a3d17081e3b8 and merge and add this : https://github.com/fedora-selinux/selinux-policy/pull/463 which is new PR of reverted commit : https://github.com/fedora-selinux/selinux-policy/pull/459
Old commit to backport: commit 74aaf7b608f6cb8147a2bead99117a9ec131c057 Author: Patrik Koncity <pkoncity> Date: Fri Oct 16 15:37:30 2020 +0200 Allow transition from xdm domain to unconfined_t domain. After removing unconfined_t domain from unpriv_userdomain attribute (BG: https://bugzilla.redhat.com/show_bug.cgi?id=1840851), missed in policy transition from xdm_t to unconfined_t. Create interface unconfined_xsession_spec_domtrans(), which allow execute an Xserver session in unconfined_t domain. Use this interface in xdm_t policy to allow transition from xdm_t to unconfined_t. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1886196 Plus a new one: commit 4b4eec49a5540459b0e89eb2c4a776ee5e9a66ac (HEAD -> rawhide, upstream/rawhide) Author: Patrik Koncity <pkoncity> Date: Fri Oct 23 19:44:45 2020 +0200 Removed adding to attribute unpriv_userdomain from userdom_unpriv_type template When is secure_mode boolean enabled the attribute unpriv_userdomain allow transition only between unprivileged users. But one member this attribute was unconfined_t domain, which had allow privilege operations. Solution was that from userdom_unpriv_type template was remove adding domains to attribute unpriv_userdomain. This template is used only for unconfined_t, so affected only uncofined domain. New PR of reverted commit: https://github.com/fedora-selinux/selinux-policy/pull/459#issuecomment-712374187 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1840851
When a staff_u user is logged in and the secure_mode boolean is enabled, the user cannot switch to unconfined_r. But the user can still log in via ssh and change the role this way: $ ssh staff-user/unconfined_r.137.32 staff-user/unconfined_r.137.32's password: Last login: Tue Jul 20 09:22:15 2021 from 10.40.193.84 [staff-user@ci-vm-10-0-137-32 ~]$ id -Z staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [staff-user@ci-vm-10-0-137-32 ~]$ getsebool secure_mode secure_mode --> on
It looks like a fix showed up in CentOS Stream 8: rpm -q --changelog selinux-policy * Fri Jul 16 2021 Zdenek Pytela <zpytela> - 3.14.3-74 - Allow dyntransition from sshd_t to unconfined_t Resolves: rhbz#1947841 ... Using secure mode, this seems to work, becoming unconfined is not allowed. [pimpampet@stream8 ~]$ getsebool secure_mode secure_mode --> on [pimpampet@stream8 ~]$ id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023 [pimpampet@stream8 ~]$ newrole -r unconfined_r Password: failed to exec shell : Permission denied Turning off the secure_mode, becoming unconfined is allowd: [pimpampet@stream8 ~]$ getsebool secure_mode secure_mode --> off [pimpampet@stream8 ~]$ newrole -r unconfined_r Password: [pimpampet@stream8 ~]$ id -Z staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 However (after turning on secure_mode once again) there are still two other options to become unconfined, despite secure mode: sudo: [pimpampet@stream8 ~]$ getsebool secure_mode secure_mode --> on [pimpampet@stream8 ~]$ sudo -r unconfined_r -i [sudo] password for pimpampet: [root@stream8 ~]# id -Z staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ssh-login: pimpampet/unconfined_r@someserver After login, the user is unconfined; despite secure_mode: [pimpampet@stream8 ~]$ getsebool secure_mode secure_mode --> on [pimpampet@stream8 ~]$ id -Z staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 The latter method even works, despite the boolean unconfined_login being off... Same bug, new bug, different bug...?
I believe that the other ways (mentioned in comment#13 and comment#15) of becoming unconfined need to be addressed in a new bug, because it's already too late in the RHEL-8.5 testing phase.
OK, newrole -r unconfined_r will no longer work. It works in CentOs Stream8 and will get to RHEL 8.5. Just confirmed it works in RHEL 8.5 Beta. But...: OK, this is very-very-very-very-premature; but trying Daily Builds CentOS Stream 9 (nine!) the fix is not available within the current build. Tested it, does not work. Checked the changelog, the fix is not there. :( Just a critical note... (did I mention this is just very premature...?)
(In reply to W. de Heiden from comment #21) > OK, newrole -r unconfined_r will no longer work. It works in CentOs Stream8 > and will get to RHEL 8.5. Just confirmed it works in RHEL 8.5 Beta. But...: > > OK, this is very-very-very-very-premature; but trying Daily Builds CentOS > Stream 9 (nine!) the fix is not available within the current build. Tested > it, does not work. Checked the changelog, the fix is not there. :( > > Just a critical note... > > (did I mention this is just very premature...?) Thanks for spotting this. It took me some time to figure out what had happened: The initial fix was reverted and later fixed again in Fedora and backported to RHEL 8, but RHEL 9 detached from Fedora in the middle of the process. I'l clone this bz.
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-2021:4420