-
Bug
-
Resolution: Done-Errata
-
Major
-
rhel-9.0.0
-
selinux-policy-38.1.27-1.el9
-
None
-
Moderate
-
rhel-sst-security-selinux
-
ssg_security
-
14
-
None
-
QE ack
-
False
-
-
Yes
-
None
-
Bug Fix
-
-
Done
-
-
All
-
None
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
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-rr-. 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.
- external trackers
- links to
-
RHBA-2023:121166 selinux-policy bug fix and enhancement update
- mentioned on