RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1947841 - Secure_mode boolean allows staff SELinux user switch to unconfined
Summary: Secure_mode boolean allows staff SELinux user switch to unconfined
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.3
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: 8.5
Assignee: Patrik Koncity
QA Contact: Milos Malik
Khushbu Borole
URL:
Whiteboard:
Depends On:
Blocks: 1778780 2021529 2022763 2076681
TreeView+ depends on / blocked
 
Reported: 2021-04-09 11:34 UTC by Renaud Métrich
Modified: 2022-04-19 16:25 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.14.3-74.el8
Doc Type: Bug Fix
Doc Text:
.SELinux policy now prevents `staff_u` users from switching to `unconfined_r` Previously, when the `secure_mode` boolean was enabled, `staff_u` users could incorrectly switch to the `unconfined_r` role. As a consequence, `staff_u` users could perform privileged operations affecting the security of the system. With this fix, SELinux policy prevents `staff_u` users from switching to the `unconfined_r` role using the `newrole` command. As a result, unprivileged users cannot run privileged operations.
Clone Of:
: 2021529 2022763 2076681 (view as bug list)
Environment:
Last Closed: 2021-11-09 19:43:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:
kborole: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:4420 0 None None None 2021-11-09 19:43:42 UTC

Description Renaud Métrich 2021-04-09 11:34:13 UTC
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.

Comment 1 Patrik Koncity 2021-06-07 11:18:25 UTC
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

Comment 2 Zdenek Pytela 2021-07-13 16:18:40 UTC
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

Comment 13 Milos Malik 2021-07-20 13:26:21 UTC
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

Comment 15 W. de Heiden 2021-07-29 10:24:42 UTC
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...?

Comment 16 Milos Malik 2021-09-02 07:03:02 UTC
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.

Comment 21 W. de Heiden 2021-10-21 13:39:38 UTC
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...?)

Comment 25 Zdenek Pytela 2021-11-09 14:32:12 UTC
(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.

Comment 26 errata-xmlrpc 2021-11-09 19:43:05 UTC
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


Note You need to log in before you can comment on or make changes to this bug.