The remove_name is not allowed for file labeled root_t:

# sestatus  | grep "policy name"
Loaded policy name:             mls
# sesearch -A -s init_t -t root_t -p remove_name
<>


    This is allowed by the targeted policy (until now):


# sestatus  | grep "policy name"
Loaded policy name:             targeted
# sesearch -A -s init_t -t root_t -p remove_name
allow named_filetrans_domain mountpoint:dir { add_name getattr ioctl lock open read remove_name search write };

Hi, 

please follow the documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/using_selinux/index#using-multi-level-security-mls_using-selinux

Permissive mode is required for smooth transition to MLS system. 
Also instead of "touch /.autorelabel" is better option "fixfiles -F onboot" as defined in documenation, because this command ensures full relabeling of the entire filesystem.

Hi Nikola,

I'm reopening the bug because there is definitely an issue here, as Benoit stated.

The system is not being moved from Targeted to MLS, which requires moving persistently to permissive as stated in the documentation.
Here the system is already in MLS+Enforcing.

In such case, as Benoit states, `touch /.autorelabel` (or using `fixfiles -B onboot`) as *root* user (once changed role) and rebooting ends up in a deadloop, because `/.autorelabel` cannot be deleted, as shown below:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[root@vm-mls9 ~]# newrole -r sysadm_r
Password: 
[root@vm-mls9 ~]# fixfiles -B onboot
System will relabel on next boot
[root@vm-mls9 ~]# ls -lZ /.autorelabel 
-rw-r--r--. 1 root root root:object_r:etc_runtime_t:s0 14 Aug 10 09:01 /.autorelabel
[root@vm-mls9 ~]# reboot
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Console output:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[    3.171691] selinux-autorelabel[663]: /usr/libexec/selinux/selinux-autorelabel: line 37: echo: write error: Permission denied^M 
[    3.172827] selinux-autorelabel[663]: *** Warning -- SELinux mls policy relabel is required.^M
[    3.173509] selinux-autorelabel[663]: *** Relabeling could take a very long time, depending on file^M
[    3.174273] selinux-autorelabel[663]: *** system size and speed of hard drives.^M
[    3.174946] selinux-autorelabel[663]: Running: /sbin/fixfiles -T 0 -N 2023-08-10  restore^M
...
[   12.662176] selinux-autorelabel[1051]: rm: cannot remove '/.autorelabel': Permission denied^M
... reboot ...

... looping on the relabeling+reboot because of the presence of '/.autorelabel' ...
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This is expected. autorelabel requires `permissive` to work reliably. It even tries to switch to `permissive` on its own - https://gitlab.com/redhat/centos-stream/rpms/policycoreutils/-/blob/c9s/selinux-autorelabel?ref_type=heads#L37

Looking into policy, I see that `init_t` is not allowed to do that:

# sesearch -A -c security -p setenforce
allow can_setenforce security_t:security setenforce; [ secure_mode_policyload ]:False

# seinfo -xacan_setenforce

Type Attributes: 1
   attribute can_setenforce;
        anaconda_t
        firstboot_t
        install_t
        preupgrade_t
        rpm_script_t
        secadm_t
        semanage_t
        sysadm_t

Given that mls needs to meet a very narrow set of security requirements based on information management in rigidly controlled environments, it's kind of expected that init daemon can't switch the state on its own. Therefore a administrator needs to change the state before reboot if they want to use autorelabel.

Or they can relabel the filesystem on their own:

# /sbin/fixfiles -T 0 -F restore

Let's assume it's expected (even though I think it's overkill and unusable in customer context).

Then you cannot use `fixfiles -B onboot` with current implementation because the command will touch /.autorelabel.
Upon reboot, you'll enter a deadloop.

So this means `fixfiles -B onboot` has to be fixed to automagically make next boot run in Permissive, then switch back automagically to Enforcing after relabeling occurred ...

mls policy is really supposed to be strict and it's not expected that every tool and option would work with it. Administrators could create local policies which allow particular functionality limited by default policy.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.