Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-38389

RHEL-10: "Rescue a RHEL system" causes endless reboot loop when system uses "mls" policy

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • rhel-10.0.beta
    • rhel-10.0.beta
    • anaconda
    • None
    • anaconda-40.22.3.8-1.el10
    • None
    • None
    • rhel-sst-installer
    • ssg_front_door
    • 14
    • None
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Red Hat Enterprise Linux
    • None
    • Known Issue
    • Hide
      Cause (the user action or circumstances that trigger the bug):
      When accessing a file system in rescue mode, this leads to the SELinux autorelabel trigger on the next boot, which may not work properly unless it is running in permissive mode.

      Consequence (what the user experience is when the bug occurs):
      In such a case the system may end up in an infinite reboot loop after exiting from rescue mode because the it will not be able to delete the .autorelabel file.

      Workaround (if available):
      Switch to permissive mode by adding "enforcing=0" to the kernel command line.

      Result (mandatory if the workaround does not solve the problem completely):
      As a solution, a warning message was added, informing about the possibility of this behavior when accessing a file system in rescue mode and how to properly avoid it.
      Show
      Cause (the user action or circumstances that trigger the bug): When accessing a file system in rescue mode, this leads to the SELinux autorelabel trigger on the next boot, which may not work properly unless it is running in permissive mode. Consequence (what the user experience is when the bug occurs): In such a case the system may end up in an infinite reboot loop after exiting from rescue mode because the it will not be able to delete the .autorelabel file. Workaround (if available): Switch to permissive mode by adding "enforcing=0" to the kernel command line. Result (mandatory if the workaround does not solve the problem completely): As a solution, a warning message was added, informing about the possibility of this behavior when accessing a file system in rescue mode and how to properly avoid it.
    • Proposed
    • None

      What were you trying to do that didn't work?

      Please provide the package NVR for which bug is seen:

      How reproducible:

      Always

      Steps to reproduce

      1. switch to SELinux MLS policy - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_selinux/using-multi-level-security-mls_using-selinux#switching-the-selinux-policy-to-mls_using-multi-level-security-mls
      2. Boot the RHEL9.2 DVD in Troubleshooting
      3. Choose rescue a RHEL system
      4. 1) Continue and hit Enter to get a shell
      5. reboot

      Expected results

      Actual results

      Anaconda rescue mode creates /mnt/sysroot/.autorelabel in order to trigger selinux autorelabel mechanism - https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py#L209

      After reboot, the system boots mls in enforcing; and in mls (which is supposed to be strict policy) init_t is not allowed to switch to permissive on its own:

      [    3.864771] audit: type=1400 audit(1697479290.335:6): avc:  denied  { setenforce } for  pid=716 comm="selinux-autorel" scontext=system_u:system_r:init_t:s0-s15:c0.c1023 tcontext=system_u:object_r:security_t:s15:c0.c1023 tclass=security permissive=0
[    3.868487] selinux-autorelabel[716]: /usr/libexec/selinux/selinux-autorelabel: line 37: echo: write error: Permission denied

      and therefore it can't later remove /.autorelabel and system goes to endless reboot loop until users add `enforcing=0` to kernel command line.

      The following shell snippet would fix labeling issues directly in the rescue shell without need to trigger autorelabel:

      source /mnt/sysroot/etc/selinux/config
setfiles -c /mnt/sysroot/etc/selinux/$SELINUXTYPE/policy/policy.33 -r /mnt/sysroot /mnt/sysroot/etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /mnt/sysroot

              rh-ee-akankovs Adam Kankovsky
              rhn-engineering-plautrba Petr Lautrbach
              Adam Kankovsky
              anaconda-maint-list anaconda-maint-list
              Release Test Team Release Test Team
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: