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

autorelabel with selinux-policy-mls in enforcing leads to endless loop - permission denied because of wrong context

Details

    • selinux-policy-38.1.27-1.el9
    • Normal
    • sst_security_selinux
    • ssg_security
    • 14
    • QE ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Hide

      Even if a RHEL-9 machine runs the MLS policy, a performed autorelabel of filesystems runs and ends successfully without causing an endless loop. The autorelabel process removes the /.autorelabel file successfully.

      Show
      Even if a RHEL-9 machine runs the MLS policy, a performed autorelabel of filesystems runs and ends successfully without causing an endless loop. The autorelabel process removes the /.autorelabel file successfully.
    • Pass
    • Bug Fix
    • Hide
      Cause (the user action or circumstances that trigger the bug):
      Policy does not assign a private type for /usr/libexec/selinux/selinux-autorelabel.
      Consequence (what the user experience is when the bug occurs):
      The selinux-autorelabel.service may fail to work in SELinux mls policy.

      Fix (what has changed to fix the bug; do not include overly technical details):
      /var/run/tmpfiles.d/static-nodes.conf is labeled with kmod_var_run_t.
      Result (what happens now that the patch is applied):
      The selinux-autorelabel.service runs successfully in SELinux mls policy.
      Show
      Cause (the user action or circumstances that trigger the bug): Policy does not assign a private type for /usr/libexec/selinux/selinux-autorelabel. Consequence (what the user experience is when the bug occurs): The selinux-autorelabel.service may fail to work in SELinux mls policy. Fix (what has changed to fix the bug; do not include overly technical details): /var/run/tmpfiles.d/static-nodes.conf is labeled with kmod_var_run_t. Result (what happens now that the patch is applied): The selinux-autorelabel.service runs successfully in SELinux mls policy.
    • Proposed

    Description

      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:

      ~~~

      1. 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.

      Attachments

        Activity

          People

            rhn-support-zpytela Zdenek Pytela
            rhn-support-bwelterl Benoit Welterlen
            Nikola Kňažeková Nikola Kňažeková (Inactive)
            Milos Malik Milos Malik
            Jan Fiala Jan Fiala
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

              Created:
              Updated: