Description of problem: Put system in mls/enforcing mode. Execute "touch /.autorelabel" and "reboot" in terminal to relabel the whole system. Once the system reboots, there is an error "selinux-autorelabel" /usr/libexec/selinux/selinux-autorelabel: line 37: echo: write error: Permission denied". Reboots and repeats the same process. This puts the system in continuous loop of reboots. We know that autorelabel must be executed in permissive mode, but anyway, it's not good to have AVC during the process and the risk to have a endless loop of a well labelled filesystem. Version-Release number of selected component (if applicable): RHEL9 selinux-policy-mls-34.1.29-1.el9_0.2.noarch How reproducible: always Steps to Reproduce: 1. Put system in mls/enforcing mode 2. touch /.autorelabel 3. reboot in enforcing Actual results: The relabel is running in init_t context, which is not allowed to remove_name in root_t of /: ~~~ Jan 27 13:41:32 localhost systemd[1]: Starting Relabel all filesystems... Jan 27 13:41:32 localhost selinux-autorelabel[757]: /usr/libexec/selinux/selinux-autorelabel: line 37: echo: write error: Permission denied Jan 27 13:41:32 localhost systemd[1]: Received SIGRTMIN+21 from PID 406 (plymouthd). Jan 27 13:41:32 localhost systemd[1]: Received SIGRTMIN+21 from PID 406 (plymouthd). Jan 27 13:41:32 localhost selinux-autorelabel[757]: *** Warning -- SELinux mls policy relabel is required. Jan 27 13:41:32 localhost selinux-autorelabel[757]: *** Relabeling could take a very long time, depending on file Jan 27 13:41:32 localhost selinux-autorelabel[757]: *** system size and speed of hard drives. Jan 27 13:41:32 localhost selinux-autorelabel[762]: cat: /.autorelabel: Permission denied Jan 27 13:41:38 localhost selinux-autorelabel[764]: Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /run /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug /sys/kernel/tracing Jan 27 13:42:02 localhost selinux-autorelabel[1089]: Warning no default label for /dev/mqueue Jan 27 13:42:02 localhost selinux-autorelabel[764]: Cleaning up labels on /tmp Jan 27 13:42:02 localhost selinux-autorelabel[1109]: rm: cannot remove '/.autorelabel': Permission denied Jan 27 13:42:02 localhost kernel: kauditd_printk_skb: 52 callbacks suppressed Jan 27 13:42:02 localhost kernel: audit: type=1400 audit(1674823322.853:63): avc: denied { remove_name } for pid=1109 comm="rm" name=".autorelabel" dev="dm-0" ino=553032 scontext=system_u:system_r:init_t:s0-s15:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0 ~~~ - autorelabel should run in a different context, policy_manager_domain ? Expected results: - autorelabel allowed to read and remove ./autorelabel Additional info: - If the /.autorelabel is created in permissive, with the current default role of root (staff_t - this is also an issue), it will be labelled root_t: ~~~ # ll -Z /.autorelabel -rw-r--r--. 1 root root root:object_r:root_t:s0 0 Jan 30 14:59 /.autorelabel ~~~ Thus not readable by autorelabel (if it includes an option), and not removable also.
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.