init=/bin/bash: what a Linux login actually protects

The shortcut is sometimes described as “Linux privilege escalation”: add init=/bin/bash at boot and get a # prompt. That account omits the important part. This is not a way to become root from an ordinary unprivileged shell. It starts at the boot menu, requires the ability to edit its arguments, and only reaches the installed system’s root filesystem if that volume is accessible. It exposes the boundary between a Linux account password, control of the boot sequence, and protection of data at rest.

The Linux kernel documents init= as the path of the program to run instead of /sbin/init. If the boot chain honors it, init=/bin/bash makes Bash the first userspace process on the final root filesystem. The kernel starts that process with the privileges needed for initialization: the resulting shell is root without passing through a login screen. The hidden condition is “if the boot chain honors it.” A distribution may insert an initramfs, interpret arguments differently, or refuse this route. Observe the behavior on the actual system rather than assuming it.

Control of the boot menu comes first

Before the command, consider the operator’s position. They need a boot console, such as a local keyboard, a VM console, or an out-of-band console exposing the boot loader. They must also be able to edit the kernel entry. SSH access to an already booted session does not provide that control. An unprivileged user cannot type init=/bin/bash into a terminal and restart PID 1. The parameter is read on a new boot.

On a GRUB installation that permits editing, e opens the selected entry; add the parameter to the line that loads the kernel, then boot that modified entry. Red Hat documents temporary editing with e and Ctrl+x in its recovery procedures. The change is for that boot, not a permanent rewrite of GRUB’s configuration. The exact line (linux, linuxefi, and so on) and keys depend on boot loader and distribution.

The root filesystem must then be available. On an unencrypted disk, the initramfs can mount it and pass control to the selected program. The switch_root manual explains this handoff from the initial root to the real root and new init. With LUKS, the operator normally needs the decryption passphrase or an already authorized method of opening the volume. A policy tied to TPM measurements can refuse to open it after a changed kernel command line. Ubuntu’s encryption documentation describes these models. Seeing a shell in the initramfs does not mean the encrypted volume holding /etc, data, and secrets has been mounted.

The boot loader may also demand a password before allowing edits. Red Hat’s GRUB protection guidance distinguishes protected editing from merely booting an existing entry. A GRUB password is no substitute for encryption if an adversary can boot other media and read an unencrypted disk. Conversely, Secure Boot alone verifies elements of the boot chain according to its configuration; it does not necessarily forbid editing every kernel argument. The relevant control is the actual editing policy and, for data protection, how access to the encrypted disk is tied to the boot chain.

A VM exercise that answers one question

The following is an exercise for a VM you own, not a claim that rootzero already performed this test. Take a snapshot of a Linux distribution with an accessible GRUB console and an unencrypted root filesystem. First record its version, boot loader, and encryption mode. Shut the VM down, open its boot menu, edit only the current entry, and append init=/bin/bash to the kernel line. Boot the temporary entry.

If Bash appears, do not mistake the shape of the prompt for proof. Read the identity and boot path:

id -u
cat /proc/cmdline
readlink /proc/1/exe
findmnt -no SOURCE,OPTIONS /

The expected result, on a VM where this route works, is 0 for the UID, init=/bin/bash in the command line, /bin/bash (or its real target) for process 1, and a root mount often in read-only mode. Some images have not mounted /proc yet or lack findmnt in the reached environment; the absence of these commands neither proves nor refutes the result. Read whichever observations are available. Leave /etc/shadow alone: id -u and process 1 establish the teaching point without changing an account.

Password-reset recipes often include mount -o remount,rw /. That remount gives write capability if the root is mounted and its filesystem allows it, changing the character of this exercise. Leave the volume read-only here. Avoid exit, too: terminating PID 1 can cause a kernel panic. Power off or reset the VM from the hypervisor, boot its normal entry without the added parameter, then return to the snapshot if you require an identical state.

A failed attempt teaches something when described precisely. GRUB menu locked? The control stopped entry editing. LUKS prompt without the secret? The volume stayed closed. Early shell with no final root? You are still in the initramfs. Normal desktop boot? The chain may have ignored or replaced the parameter. On RHEL, rd.break is a separate documented recovery path that stops in the initramfs before switching to the final root; it is not another spelling of init=/bin/bash. (Red Hat procedure)

Protect the console and boot chain

A user password answers “who may open a session on this running system?” It does not answer “who chooses what the kernel starts before any sessions exist?” On a workstation exposed to physical access or a management console, defenses therefore have several layers: limit and audit access to that console, protect boot-loader editing, control bootable media, encrypt sensitive volumes, and verify how the encrypted volume becomes accessible. For a production VM, the hypervisor console is itself an administrative capability to govern.

The test report should specify the distribution, boot loader, initramfs, encryption, GRUB state, exact argument, observed UID and / mount. These details allow others to reproduce the result and identify which control needs changing.