Using GRUB 2

Securing GRUB 2

By default, you can modify the GRUB 2 configuration only if you have administrator rights; normal users do not have access.

You can increase GRUB 2 security further by applying a password [6] so that not just anyone is allowed to play with the boot options or start the system. To set a password, in the /etc/grub.d/40_custom file, add the following entry using your own password:

set superusers="felix"
password felix secret

Here, only user felix can alter GRUB by entering the password secret .

Because Felix's password appears as plaintext in the file, you can create an even more secret password by using the command:

$ sudo grub-mkpasswd-pbkdf2

The pbkdf2 function (password-based key derivation function 2) first requests the user's password and then spits out a very long hashed string (Figure 3).

Figure 3: At the command line, you can create an encrypted password to access GRUB 2.

You can use this hardened password for Felix in place of $PASSWORD in the following command:

$ password_pbkdf2 felix $PASSWORD

Once again, enter sudo update-grub to generate a new configuration file for GRUB 2. By the way, using sudo grub-mkconfig shows you the modified configuration in advance.

Secure Boot

A new mechanism known as Secure Boot (the Unified Extensible Firmware Interface, or UEFI, specification) crops up in many discussions. It is a mechanism that Microsoft claims makes the boot process more trustworthy [7]. It first appeared with Windows 8 and applies to multiboot systems in particular. With UEFI, a certificate from a Microsoft-authorized certificate authority has to be applied at boot time.

If Secure Boot is activated on the computer (on ARM machines it can't be deactivated), the system starts up only if all the boot process modules have a valid certificate; otherwise, nothing loads on the computer. The posited advantage of this approach is that a computer loads only trustworthy – pre-tested – components from a reliable source, which prevents malicious code from creeping in.

However, Secure Boot makes development and testing of unsigned kernel modules more difficult. It's not the process itself, which is supposed to add security, that is the problem, but Microsoft's role that pushes Secure Boot through as a quasi-standard by virtue of Microsoft's market position.

Linux distributions each have a way of handling secure booting. Red Hat/Fedora, openSUSE, and Ubuntu use a signed bootloader, with Red Hat/Fedora also adding a signed kernel. OpenSUSE enhances the process with its own key management system. Debian developers meanwhile haven't made any statements on the subject.