Bug 2165599

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.