Summary: Although sulogin will prevent some forms of access to a root shell, preventing other methods of passing command-line arguments to the kernel requires a bit more.

In last week's article, I showed you how to enter single user mode at the lilo prompt, ala:

lilo: linux single

or

lilo: linux 1

Both of those arguments tell init to boot into runlevel 1. If you have sulogin set to run, then single user mode is only available if you know the actual root password, which is a good thing. However, another method exists for you to gain passwordless root access without using single user mode at all.

Normally, the linux kernel will launch /sbin/init once it's finished loading. init is responsible for starting all the programs appropriate for your given runlevel based on the entries in the /etc/inittab file. That's why init is always process #1 when you do a 'ps'. However, we can tell the Linux kernel to run a different program instead of /sbin/init by using the 'init=' option on the lilo command line:

lilo: linux init=/bin/bash

Now the kernel will launch /bin/bash as root. Viola! A root shell, no questions asked. You could run anything you wanted, but /bin/bash is probably the most convenient method.

When you boot Linux in this manner, you'll find that your disks are mounted read-only[1]. Once you're at a shell though, fixing this is trivial:

# fsck /
# mount -orw,remount /

So you can see that enabling sulogin is not sufficient to prevent someone at the console from getting a root shell; you must create password restrictions for your kernel definitions to prevent anyone from passing command-line arguments to the kernel. I showed you how to do this last week, but let's recap.

Add 'restricted' and 'password' options to the relevant /etc/lilo.conf kernel definition[2]:

image=/boot/vmlinuz
	label=linux
	restricted
	password=suLoginIsntSufficient
	read-only
	root=/dev/hda7

Of course, don't forget to make the lilo.conf file unreadable by local users:

# chmod 600 /etc/lilo.conf

And now re-run lilo when you're done:

# lilo

If you're paranoid, then you can always make lilo.conf immutable (unchangeable) with chattr[3]

# chattr +i /etc/lilo.conf

If you ever do need to make changes, then you'll need to turn off the immutable bit first:

# chattr -i /etc/lilo.conf
# $EDITOR /etc/lilo.conf
# chattr +i /etc/lilo.conf

So, does this mean we're completely secure now? Nope, sadly not. Other ways remain that provide root access to the machine, such as booting from alternate devices like a floppy/CD[4] or just pulling out the disk and mounting it on a different machine and accessing it there directly, but we've covered the most direct and simple methods via our lilo configurations.

NOTES

[1] You could have the kernel mount '/' read write by specifying:

	lilo: linux rw init=/bin/bash

at the lilo prompt. However, I like to fsck the drive manually and remount. Call me paranoid.

[2] Actually, you can use restricted or password in the global section as well, not just in an image definition. However, I like having different passwords for each image, so I don't put 'password' in the global section. Restricted, on the other hand, is fine if you want them all restricted.

[3] chattr only works on ext2/ext3 file systems.

[4] Most BIOS can disable or password-protect the ability to boot off other devices. I leave that as an exercise for the reader so we can get onto more interesting topics again next week.

Bri Hatch is Chief Hacker at Onsight, Inc, and author of Hacking Linux Exposed and Building Linux VPNs. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 02-Jul-2002.