4 of 4

Services, Targets and BootLesson 4 of 4

Recovering root access: rd.break and SELinux relabel

Interrupt the boot before the real system starts, set a new root password, and make sure SELinux still lets you log in.

  • rd.break
  • mount -o remount,rw /sysroot
  • chroot /sysroot
  • passwd
  • touch /.autorelabel
  • restorecon
  • rescue.target

40 min4 exercises

After this lesson you can

  • Reset a forgotten root password by interrupting the boot at the initramfs.
  • Explain each step: why /sysroot is read-only, why chroot, why the relabel file.
  • Recognise the other recovery options (rescue and emergency targets) and when each fits.

The idea

Physical or console access beats a forgotten password: you can tell the boot loader to stop early, before the login and authentication stack starts, and edit the system directly. On RHEL the standard method is rd.break.

rd.break makes the kernel pause in the initramfs (the temporary root used to find the real one) just before it switches to the real root file system. At that moment the real root is mounted at /sysroot, read-only, and you have a root shell with no password prompt. From there:

  1. mount -o remount,rw /sysroot because it is read-only until now; without this passwd fails with a read-only file system error.
  2. chroot /sysroot so /etc/shadow and the tools refer to the real system, not the initramfs.
  3. passwd root and type the new password twice.
  4. touch /.autorelabel because the initramfs has no SELinux policy loaded, so the rewritten /etc/shadow gets the wrong label. In enforcing mode, logins would then be denied with the correct password. The marker file tells the next boot to relabel every file.
  5. exit to leave the chroot, exit again to continue booting. The relabel runs, the system reboots by itself and the new password works.

The other recovery targets from the previous lessons need the root password: rescue and emergency mode will prompt for it. If you know it, they are the tools for repairing a broken /etc/fstab or a service that prevents login. If you do not, rd.break is the only one of these that works.

Try it

This is a console exercise: do it in a virtual machine and take a snapshot first.

rd.break

Press Ctrl+x to boot. After a short time the screen shows:

switch_root:/#
mount -o remount,rw /sysroot
chroot /sysroot
sh-5.2#
passwd root
touch /.autorelabel
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
exit
exit

The machine boots, relabels the file system (this can take a minute or several on a large disk), and reboots once more. Then log in as root with the new password. Verify:

getenforce
ls /.autorelabel
Enforcing
ls: cannot access '/.autorelabel': No such file or directory

Which tool, when

SituationMethod
Root password lostrd.break
Password known, system boots but a service blocks the loginsystemd.unit=rescue.target
Password known, boot drops to a maintenance prompt (bad fstab, missing disk)Enter the password at the prompt, fix, reboot
Filesystem damageemergency.target, then fsck / xfs_repair on an unmounted device

In the exam

This task appears often: “You cannot log in as root. Reset the password to X.” The steps are the five above, in that order. Practice until you can do it from memory in under three minutes. Type slowly: at the initramfs prompt a typo in chroot /sysroot leaves you changing the wrong system. Also check the keyboard layout when you type the new password, since the console may not use the layout you expect.

Going further

Instead of rd.break you can append init=/bin/bash, but then systemd never starts and the rest of the steps are fiddlier, so use rd.break. If the boot menu is protected by grub2-setpassword, you need that GRUB password first. On encrypted disks the LUKS passphrase is asked before the file system is available; recovery of root there still needs the passphrase. After any recovery, review last and journalctl -b for what happened before the lockout, and change any other password you suspect was known to someone else.

Practice

0 of 4 done

Do these on your own system. They get harder. Check each result, then tick it off.

  1. Practice

    Reset the root password from the console

    In your lab VM (take a snapshot first), reboot and edit the GRUB entry: append rd.break to the linux line, boot with Ctrl+x. At the switch_root:/# prompt remount /sysroot read-write, chroot into it, set the root password to NewPass123, create the SELinux relabel marker, exit twice, and wait for the reboot. Then log in as root with the new password.

    Check your result

    After the reboot you can log in as root with NewPass123. ls /.autorelabel is gone (it is removed after the relabel). ausearch -m avc -ts boot shows no denials for login.

    Hint

    The sequence: mount -o remount,rw /sysroot, chroot /sysroot, passwd root, touch /.autorelabel, exit, exit. The relabel makes the first boot slower.

    Solution
    At GRUB: press e, add  rd.break  at the end of the linux line, Ctrl+x

switch_root:/# mount -o remount,rw /sysroot
switch_root:/# chroot /sysroot
sh-5.2# passwd root
sh-5.2# touch /.autorelabel
sh-5.2# exit
switch_root:/# exit
  2. Warm-up

    Explain it to a colleague

    Write one sentence each answering: why is /sysroot read-only at that prompt, what does chroot /sysroot change, and what breaks if you skip touch /.autorelabel while SELinux is enforcing?

    Check your result

    Answers: the real root is mounted read-only (ro on the command line) until the system finishes booting; chroot makes /sysroot the root so passwd edits the real /etc/shadow; without relabel the new /etc/shadow has the wrong SELinux context and logins are denied.

    Hint

    Think about which process edits /etc/shadow and what label a file created by an initramfs shell gets.

    Solution
    1. The kernel mounts the real root read-only; it only becomes read-write once systemd is up.
   You remount it rw yourself to be able to write.
2. After chroot, the paths /etc/shadow etc. refer to the real system, so passwd
   changes the right file and uses the real PAM configuration.
3. The initramfs has no SELinux policy loaded, so the rewritten /etc/shadow gets an
   unlabeled/wrong context. In enforcing mode, login would then be denied. The marker
   file makes the next boot relabel the whole file system.
  3. Practice

    Choose the right recovery tool

    For each situation say which method you would use and why: (a) the root password is known, a bad /etc/fstab line stops boot at the maintenance prompt; (b) the root password is lost; (c) a service blocks the login prompt and you need a shell with the file systems mounted read-write.

    Check your result

    (a) the maintenance prompt itself or emergency.target, then edit /etc/fstab; (b) rd.break; (c) systemd.unit=rescue.target.

    Hint

    Rescue and emergency modes ask for the root password; rd.break does not.

    Solution
    (a) Enter the root password at the "Give root password for maintenance" prompt,
    remount / read-write if needed, fix /etc/fstab, then reboot.
(b) rd.break: it runs before login, so no password is needed.
(c) systemd.unit=rescue.target: file systems mounted read-write, few services, root shell.
  4. Challenge

    Check nothing was left in a weakened state

    After the recovery, confirm that SELinux is still in enforcing mode (you did not boot with enforcing=0), that no .autorelabel file remains, that root can log in at the console, and that sshd still works. Record the commands as a short post-recovery checklist.

    Check your result

    getenforce prints Enforcing, ls /.autorelabel reports no such file, systemctl is-active sshd is active, and journalctl -b -u sshd shows no error.

    Hint

    Recovery steps that need enforcing=0 should be avoided; the relabel file is the proper method.

    Solution
    getenforce
ls /.autorelabel 2>&1
systemctl is-active sshd
sudo journalctl -b -u sshd --no-pager | tail -3
sudo ausearch -m avc -ts boot | head