Bypassing and Resetting Linux Passwords via the GRUB Bootloader: A Cybersecurity Perspective

Physical Access Is Root Access

Eleven keystrokes at the GRUB menu and a reboot. That is the entire distance between “I don’t have the root password” and a root shell on an unencrypted Linux box. No exploit, no CVE, no privilege escalation chain — just a kernel argument the bootloader was designed to accept.

The parameter is init=/bin/bash. It tells the kernel to skip systemd entirely and hand PID 1 to a shell. PID 1 runs as root by definition, and it starts long before login, PAM, or /etc/shadow enter the picture. There is nothing to bypass because nothing has started yet.

Two things follow from that. If you administer Linux systems, this is the recovery procedure that gets a locked-out server back without a rebuild. And if you own Linux systems that anyone can walk up to, it is the reason disk encryption is not optional. Both halves matter, so this covers the procedure on Debian and Red Hat families, then what it actually takes to close the hole.

How Boot Interception Works

Under normal circumstances, the Linux boot sequence is a handoff chain: firmware initialises the hardware, GRUB loads the kernel, the kernel starts systemd, and systemd eventually brings up the login prompt — which calls PAM to verify your credentials against /etc/shadow.

By catching the process at the GRUB menu, you can short-circuit that chain before it ever reaches the authentication layer:

The two distribution families diverge at that interception point. Debian and its derivatives let you replace init outright. Red Hat systems ship SELinux in enforcing mode, which makes the blunt approach backfire in a way that is genuinely hard to diagnose — so they get a gentler technique, rd.break, and one extra step you cannot skip.

Debian and Ubuntu-Based Systems (init=/bin/bash)

On Debian, Ubuntu, and their derivatives (Mint, Kali, Pop!_OS, etc.), you tell the kernel to use /bin/bash as its init process instead of systemd. That shell is PID 1, so it is root, and it starts before any login management or PAM authentication exists to say otherwise.

The cost of that bluntness shows up at the end: with no systemd, there is no service manager, no clean shutdown, and no journal. You are typing into a system that is barely assembled. Step 8 matters more than it looks.

Recovery Steps

1. Get to the GRUB menu. Power on the machine. For BIOS systems, hold Shift immediately after power-on. For UEFI systems, tap Esc repeatedly. Either way, you’re trying to catch the GRUB countdown before it auto-boots.

2. Edit the boot entry. Use the arrow keys to highlight the default kernel entry (usually the first one) and press e to open the parameter editor.

3. Find the linux line. Scroll down until you see the line that starts with linux. This is where the kernel image path and boot arguments live.

4. Append the shell parameter. Move to the very end of the linux line and add:

init=/bin/bash

While you’re there, look for the word ro on that line and change it to rw. This mounts the root filesystem as read-write right from the start, which saves you a step later.

5. Boot with the modified parameters. Press Ctrl + X or F10 to boot.

6. Remount the filesystem if needed. If you didn’t change ro to rw in step 4, the root filesystem is mounted read-only and passwd will fail — usually with a vague complaint about a token manipulation error rather than anything that mentions the word “read-only”. Fix it with:

mount -o remount,rw /

7. Reset the password.

passwd username

Enter the new password twice when prompted. Replace username with root or whichever account you’re recovering.

8. Reboot safely. Systemd is not running, so reboot and shutdown have nothing to talk to and will either hang or error. Do not reach for the power button either — your new hash may still be sitting in the page cache. Flush it to disk, remount read-only, then force the reboot at the kernel level:

sync
mount -o remount,ro /
reboot -f

Red Hat-Based Systems (rd.break)

RHEL, Rocky Linux, AlmaLinux, and Fedora take a different route: rd.break. The flag halts the boot just before the initial RAM disk (initramfs) pivots to the real system root, dropping you into an emergency shell while the real filesystem is still parked at /sysroot.

Then there is SELinux, which these distributions run in enforcing mode out of the box. Every file carries a security context label, and passwd running inside a chroot from the initramfs does not apply one correctly to the rewritten /etc/shadow. The failure mode is the nasty kind: the system boots normally, the login prompt appears, and your brand-new password is simply rejected. No error explains why. You reboot, try again, assume you fat-fingered it twice, and lose half an hour. Step 7 is what prevents that.

Recovery Steps

1. Get to the GRUB menu. Power on and press any key to stop the automatic countdown. Highlight your kernel version and press e to edit it.

2. Find the linux line. Look for the line starting with linux, linux16, or linuxefi — the label varies depending on the system version and whether it’s using legacy BIOS or UEFI.

3. Add the rd.break flag. Go to the end of that line, add a space, and type:

rd.break

Press Ctrl + X or F10 to boot.

4. Remount the system root. You’ll land in an emergency shell inside the ramdisk environment. The real OS filesystem is sitting at /sysroot, mounted read-only. Remount it with write access:

mount -o remount,rw /sysroot

5. Chroot into the real system.

chroot /sysroot

Now your shell is operating inside the actual OS environment rather than the ramdisk.

6. Reset the password.

passwd username

7. Trigger an SELinux relabel — don’t skip this. /etc/shadow was rewritten outside normal system operation, so its SELinux context is now wrong or absent and the authentication stack will refuse to read the new hash. Create the relabel trigger:

touch /.autorelabel

On the next boot, SELinux walks the entire filesystem and restores every label from policy. That is the trade-off — it is a full-disk pass, so budget anywhere from under a minute on a small VM to well over ten on a large spinning-disk server, during which the machine is unavailable. Skip it and you will be back at the GRUB menu doing this again.

8. Exit and let the system finish booting.

exit   # Exit the chroot
exit   # Exit the initramfs shell

The system will complete the boot, perform the SELinux relabeling pass, and then present the normal login screen with your new password active.

Hardening Against Boot Bypasses

Everything above works because the boot chain is designed to be steerable by whoever is at the console. You cannot remove that property — you can only make each link cost something. The controls below are ordered by how much they actually buy you, which is not the order most hardening guides use.

1. Full Disk Encryption (FDE with LUKS)

This is the only control on the list that defeats the attack rather than inconveniencing it. With LUKS active, the partition holding /etc/shadow is ciphertext. init=/bin/bash still works perfectly — the attacker gets their root shell, and it is useless, because the kernel cannot mount a volume it cannot decrypt. Everything else here is a delay; this is a wall.

The trade-off is real and worth stating. An encrypted root partition needs a passphrase at every boot, which means an unattended server reboot after a power cut leaves the machine sitting at a prompt until someone types it in. Teams work around this with TPM-bound keys or network-bound decryption (Clevis and Tang), and both add moving parts that can themselves fail. Forget the passphrase and there is no recovery procedure at all — that is the point of it.

2. Password-Protect GRUB

By default, GRUB hands the parameter editor to anyone with a keyboard. Requiring a password for that is cheap and worth doing — with the caveat that it protects the menu, not the disk. Someone who pulls the drive and mounts it on another machine never sees GRUB at all.

Generate a hashed password:

grub-mkpasswd-pbkdf2

Copy the output hash (it starts with grub.pbkdf2.sha512...) and add it to your GRUB custom config:

cat <<EOF >> /etc/grub.d/40_custom
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.YOUR_HASH_HERE
EOF

Then rebuild GRUB:

• Debian/Ubuntu: update-grub
• RHEL/Rocky/AlmaLinux (BIOS): grub2-mkconfig -o /boot/grub2/grub.cfg
• RHEL/Rocky/AlmaLinux (UEFI): grub2-mkconfig -o /boot/efi/EFI/$(ls /boot/efi/EFI/)/grub.cfg

Now pressing e at the GRUB menu prompts for credentials before any editing is allowed. Test this from a console before you walk away from the machine — a mistake in 40_custom can lock out normal booting as well as editing, and the place you discover that should not be a remote data centre at 2 a.m.

3. Lock Down the BIOS/UEFI

A GRUB password is worth nothing if the attacker can boot a live USB and mount your disk from someone else’s operating system. Close that path in firmware:

• Set an administrator password to prevent changes to boot settings.
• Disable booting from USB, CD/DVD, and network (PXE). Set the internal drive as the only boot device.
• Enable Secure Boot where supported — it validates the cryptographic signatures of the bootloader and kernel so only trusted binaries can run.

4. Physical Security

Every firmware control above assumes the case stays shut. Pull the CMOS battery for a minute and most BIOS passwords clear themselves; many boards expose a reset jumper that does the same thing in seconds. Firmware settings are a speed bump for someone with a screwdriver.

• Enable chassis intrusion detection in motherboard settings if your hardware supports it. It won’t stop the tamper, but it logs that one happened — which is often what you actually need afterwards.
• Servers belong in a locked rack in a controlled-access room. Workstations get a Kensington lock where feasible.
• Accept the hierarchy: locks and cameras buy you detection and delay, not prevention. The disk encryption in §1 is what keeps the data safe once the hardware is in someone else’s hands.

Wrapping Up

The useful thing about this technique is that it is not a flaw. Nobody needs to patch it. GRUB accepting kernel arguments is the feature that lets you rescue a machine with a broken fstab, boot an older kernel after a bad upgrade, or recover a password without a rebuild — and the same feature hands root to whoever reaches the keyboard first.

So the honest summary is a short one: on a Linux box without full disk encryption, your /etc/shadow hashes protect you from remote attackers and from nobody else. GRUB passwords, firmware locks, and locked racks all raise the effort, and are worth the small cost of configuring. Only encryption changes the outcome.