Why does Linux allow ‘init=/bin/bash’?

Question

I recently found out that if I edit GRUB before booting and I add rw init=/bin/bash I end up with a root shell.

Being in a condition that I want to understand everything I would like to know why this happens. I mean is it a bug? is it a feature? is it there to help admins to fix things as it only works if you have physical access to a computer?

Is it provided by GRUB or the actual kernel?

Answer 1

This is a feature, and is used for system maintainance: it allows a sysadmin to recover a system from messed-up initialization files or change a forgotten password.

This post in the Red Hat mailing list explains some things:

In Unix-like systems, init is the first process to be run, and the ultimate ancestor of all processes ever run. It's responsible for running all the init scripts.

You're telling the Linux kernel to run /bin/bash as init, rather than the system init. [...]

Thus, you are not exploiting anything, you are just using a standard kernel feature.

Besides, as noted in a comment, the rw flag is separate from init=, it just tells the system to mount the root file system as read-write (so you can e.g. edit the misconfigured file or change a password).

Answer 2

Your system has mechanisms for running and debugging (like the init parameter) and it probably has security mechanisms to stop unwanted users from taking advantage of them. These are features, not bugs.

The bootloader is responsible for starting the OS. OS security obviously doesn't apply at that point. You could just load a different kernel, initrd, root fs or set different options (like init path). If you want to stop users from doing that, it must be done at the bootloader.

Your system (probably a PC, so BIOS) loads the bootloader and so, obviously, bootloader security doesn't apply to it. If you want to stop users from making the bios boot from USB or such, you need to do that on that level.

Your system may be on a desk somewhere. If you want to stop users from opening the coputer and switching the hdd for one of their own or removing the drive to mount it in their machines, you need to do it on a physical level. And it won't stop them from picking up the whole desk and driving away in their getaway van...

That's the way security is. Elephants all the way down.

Answer 3

This is simply how the kernel was designed. There has to be something to run when the computer starts, and while there is a default, the kernel command line allows you to change that default.

Normally it runs a program called "init", usually found at /bin/init or /sbin/init. This program is responsible for all the system startup and creating a usable environment.

Specifying init=/bin/bash tells the kernel to run /bin/bash instead (which is a shell). Specifying rw tells the kernel to boot with the hard disk in read-write mode instead of read-only mode. Traditionally the kernel starts with the disk in read-only mode and a process later on checks the integrity of the disk before switching to read-write.

Answer 4

Pieced together from kernel.org:

KNL     Is a kernel start-up parameter.

init=   [KNL]
        Format: <full_path>
        Run specified binary instead of /sbin/init as init
        process.

rw      [KNL] Mount root device read-write on boot

Answer 5

init= can take any executable

init= can take any executable, including shell scripts. The underlying reason is likely that the exec syscall can directly handle both ELF executables and shebangs.

Here for example I demonstrate how to create an arbitrary minimal C compiled init: How to create a custom Linux distro that runs just one program and nothing else?

So why would it not accept /bin/bash, of all things, which is just a regular executable, and can actually be useful? :-)

Next, you should also to try to understand what the trade-offs will be with your regular init such as systemd or Busybox'

Basically, with a raw /bin/bash, you:

• lose the ability to control login with passwords. But this is sometimes desirable, e.g. when doing system emulation: How to login automatically without typing the root username or password in Buildroot BusyBox init?
• lose job control, e.g. Ctrl + C won't work
• if you do Ctrl+C, the shell exits, and the kernel panics since init existed

Job control can be restored on Busybox' init and other similar inits with a leading - in the inittab:

tty3::respawn:-/bin/sh

The more normal inittab entries, which use login and keep spawning shells if you do Ctrl+D are:

::respawn:/sbin/getty -L ttyS0 0 vt100

which use the getty executable, but TODO: I haven't been able to spawn those myself without the Busybox init: getty start from command line?

You can use this setup to play around with it and reach the above conclusions.

Answer 6

This is a feature from the kernel: it allows its “caller”, i.e. the boot loader, great flexibility. Grub provides you with the means to make use of this flexibility while booting, but it also provides you with the means to restrict this kind of tampering. This makes particular sense in those cases where unauthorized users may get hold of the boot process, but are otherwise denied access to the hard drive itself.