A Discussion on Grub Security

By | 2007/06/22

Today’s post isn’t so much a tutorial but more of a discussion or educational topic on grub.  It was inspired by the original post here and continued discussion in the comments.  I thought I would outline some suggestions on securing the grub boot loader and why Ubuntu adding a “rescue mode” entry in grub is not a security flaw and is really not any less secure than any other distribution.

(based on how long this entry has become I added the split post.  If you’d like to read a long entry, click read more.  If you’re not in the mood for a 10min read, relax and forget it.)

To understand this you’ll need to be familiar with Linux runlevels.  There are six default runlevels in the Linux base system.

0 (zero) is basically the shutdown runlevel.

1 (one) is single user mode.

2 (two) is a multi-user mode, minus NFS support.

3 (three) is a multi-user, command line based mode.

4 (four) user-defined / undefined.

5 (five) multi-user, graphical mode.  This is generally the default runlevel on desktop / laptop machines.

6 (six) is basically the reboot runlevel.

For the most part you don’t often use runlevel 1 or 2, primarily only use 3 on servers and 0 and 6 are used when you shutdown or reboot the machine.  5 is most likely the default on your system now.

The reason that I outline this topic in relation to grub, security and “rescue mode” is that the option included in Ubuntu for “rescue mode” is basically just an entry that boots the machine into runlevel 1 instead of the default 5.

The default behaviour for runlevel 1 is to boot to a basic shell, not require a login and allow the user to do recovery or maintenance.  Some people feel that this is a security flaw and that allowing root access to a machine via an entry in grub is simply absurd.  This same access can be achieved on most Linux distributions.

If you’d like to try it yourself (yes, this also applies to Fedora, RHEL, etc) boot your machine and press a key at grub.  You should see a menu for your available kernels and can boot any of them by selecting them and pressing ENTER.

You’ll also notice a small paragraph of command tips below the menu.  This outline explains that you can edit grub entries within this interface by pressing ‘e’ or ‘a’ to append to the entry.  To boot your machine to the “recovery mode” that Ubuntu creates simply ‘a’ (to append) and add one of the following to the kernel line: 1, s, S, or single.  These options will boot your machine to runlevel 1 or single user mode, give you a shell prompt for maintenance or recovery and not prompt you for a password.

Again, this can be done on most other distributions.  It is not limited to Ubuntu and is not a security flaw.  It is built this way to allow a user to recover a lost password, update or recover configuration files, and otherwise fix an unbootable machine.

Now that we understand that the system is designed this way and this access can be granted on most any machine you have local access to we might want to discuss how to lock down the grub system to not allow grub editing.  Securing grub will, of course, further harden your machine from this potential threat but also lock you out of recovery if you forget the passphase to access grub.

Now if you decide you’d like to lockdown grub to not allow any editing you’ll need to edit the /boot/grub/menu.lst file.  This file includes any available bootable kernels you have, the Ubuntu recovery mode entries, memtest86+ and any other OS you have setup.  Most of this file is pretty straight forward, but because of the method Debian/Ubuntu use to update this file you need to make updates in certain places.  If these changes are not made in the right place they will be overwritten the next time you update your kernel.

There is an AUTOMATIC KERNELS LIST section which builds the basis for your kernel updates within grub.  We don’t need to edit anything within this section (as it will be overwritten on the next update anyway).  What we can do though, is update some of the global options that you see near the top of the file.  These include the ‘default’ value, ‘timeout’ and ‘hidemenu’.   These don’t offer any security though.  What we can add is a password entry that will limit any grub updates or alteration without the password.

The first step to do this is run the ‘grub-md5-crypt’ command.  This will generate an md5 hash of a password of your choice which can be then added to grub.

Add a line entry in grub (anywhere in the same area of the options mentioned above) using the following syntax:

password --md5 (two dashes md5) <hash>

replace <hash>, of course, with the hash value outputted by grub-md5-crypt.  You’ll end up with something like:

password --md5 $1$nL5d0$36n6u8TaxOX9guBdKaGFx0

At this point, since this password is at the top of the file and not specific to any one entry, (which can also be done by adding the same syntax to individual entries) any updates to grub will require this password.  At this point, even local access to the machine will require a password before being able to suggest an alternate runlevel or using Ubuntu’s “recovery mode”.

Your Linux machine is now one step closer to being a hardened gauntlet.  Enjoy.

7 thoughts on “A Discussion on Grub Security

  1. Liam Bedford

    Ubuntu boots to sulogin by default, which means if there is a root password set, it will ask for it.

    You can even bypass that by appending
    “init=/bin/sh” to the bootloader, and then it doesn’t matter what security you put on your machine, apart from drive encryption.

  2. Malcolm Parsons

    In most other distributions, single user mode does ask for the root password.

    Ubuntu doesn’t have a root password, so it cannot ask for it.

    There is no point in securing grub without also setting a BIOS password, or I can get a root shell by inserting a boot floppy / cd / usb flash drive.

  3. Pierce Lopez

    And then, you’d need to lock your computer in a cabinet so one can’t remove the bios memory battery or use a simple jumper to reset it… Basically, if someone has physical access to your computer, it’s been compromised(unless you have a really, really good and inconvenient full drive encryption scheme).

  4. Kevin Mark

    as directhex wrote above, (debian and) ubuntu define runlevels 2-5 the same and default to runlevel 2. Some have asked that we comply with the Redhat-like standard, but alas it has been changed.

  5. abhi

    I have just bought a Dell XPS ubuntu laptop. By this grave error I have forgotten my username and password.
    I am totally new to Ubuntu.
    How do I recover it or reset it?

  6. Bob

    Boot from an ubuntu live CD and changet it back

Comments are closed.