cbwww/site/docs/gnulinux/grub_hardening.md
Leah Rowe 58820a1a61 complete cleanup of grub.cfg docs
remove all the redundant information, and merge some of it
between the two articles (grub hardening and grub cbfs guides)

Signed-off-by: Leah Rowe <info@minifree.org>
2024-11-02 01:10:17 +00:00

10 KiB

Let's assume your board is x200_8mb, do:

./mk -m coreboot x200_8mb

Find this section: Security -> Boot media protection mechanism

In the above example, I found:

  • Lock boot media using the controller
  • Lock boot media using the chip

Which one to pick depends on your board. Let's pick "controller".

Now we can see: Security -> Boot media protected regions

In there, there is the option to ban writes, or to ban both reads and writes. Banning reads may be desirable, for example if you have a salt hashed password stored in grub.cfg! (as this guide told you to do)

You'll have to play around with this yourself. These options are not enabled by default, because Canoeboot images are supposed to allow writes by default, when booted. You have to enable such security yourself, because the design of Canoeboot is to be as easy to use as possible by defalut, which include updates, thus implying read-write flash permissions.

This example was for x200_8mb, but other boards may look different in config. Anyway, when you're done, save the config and then build it from source in cbmk.

See: build from source

IFD-based flash protection

The simplest way is to just do this:

ifdtool -x canoeboot.rom -O canoeboot.rom

If you did the step before, to compile cbfstool, you can find ifdtool in the elf/ directory, e.g. elf/ifdtool/default/ifdtool. Use the ifdtool version matching the coreboot tree for your mainboard.

Note that this only works for Intel-based systems that use an Intel Flash Descriptor, which is actually most Intel systems that Canoeboot supports.

Other facts

Strapping HDA_SDO or HDA_DOCK_EN requires physical access, because you have to short a pin on the HDA chip on the motherboard, or there will be a header for this on the board (e.g. "service mode" jumper). If you strap those pins, it disables descriptor-based flash protections.

On Dell Latitude laptops specifically, the EC can unlock flash by setting the SDO/DOCK_EN signal as described, and this is in fact what the dell-flash-unlock utility does, so you can consider IFD locking there to be basically useless.

In addition to the above, you may also consider /dev/mem protection. Enable CONFIG_STRICT_DEVMEM in your Linux kernel, or set securelevel above zero on your BSD setup (but BSD cannot be booted with GRUB very easily so it's a moot point).

FLILL

On Intel Flash Descriptor, you can insert up to four (4) commands on a list within, called FLILL; not yet documented, but any SPI command listed here would no longer work during internal flash operations. For example, you could use it to disable certain erase/write commands. You could also use it to disable reads.

PRx registers

Protected Range registers are available on Intel platforms, to disable flash writes. This is not yet documented, and it varies per platform.

GRUB Password

The security of this setup depends on a good GRUB password as GPG signature checking can be disabled through the GRUB console with this command:

set check_signatures=no

The above GRUB shell command is required when you want to live USB media, or other Linux setups that don't yet have signatures on files e.g. linux.

We will assume that you're using the default GRUB tree; the GRUB CBFS guide linked above tells you how to determine which GRUB tree to use.

The following executable will then be available under src/grub/default/:

grub-mkpasswd-pbkdf2

Run that program. It will ask you to choose a new passphrase. Its output will be a string of the following form:

grub.pbkdf2.sha512.10000.HEXDIGITS.MOREHEXDIGITS

Put this before the menuentries (just before) in grub.cfg, but note that you should not literally use what is below; the hash below is not the one you generated yourself. Make sure to adapt accordingly.

Example:

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711

Again, replace it with the correct hash that you actually obtained for the password you entered. In other words, do not use the hash that you see above!

GRUB will also ask for a username in addition to the password; the "root" user is specified above, but you can cahnge it to whatever you want.

Unset superusers

Find this line in grub.cfg:

unset superusers

Change it to this:

# unset superusers

Commenting it, as shown above, ensures that password authentication works, because unset superusers in fact disables passwordh authentication, so it's very important that you comment out this line.

Disable the SeaBIOS menu

Very important. Make sure you read this carefully.

In releases after Canoeboot 20240510, SeaBIOS is the primary payload on all images, but GRUB is available in the boot menu.

Do this:

cbfstool canoeboot.rom add-int -i 0 -n etc/show-boot-menu

This disables the SeaBIOS menu, so that it only loads GRUB.

If your ROM image doesn't auto-start GRUB, you should also insert the bootorder file:

cbfstool canoeboot.rom add -f config/grub/bootorder -n bootorder -t raw

This bootorder file has the following contents:

/rom@img/grub2

Release images with seagrub in the name already have this bootorder file, so you only need to disable the menu on these images. If you have the image with seabios in the name (instead of seagrub), you must do both.

SeaBIOS option ROMs

SeaBIOS will also still execute PCI option ROMs. Depending on your preference, you may wish to disable this, but please note that this will break certain things like graphics cards. More information is available here:

https://www.seabios.org/Runtime_config

If you're using a graphics card, you need VGA option ROMs at least.

GPG keys

First, generate a GPG keypair to use for signing. Option RSA (sign only) is ok.

WARNING: GRUB does not read ASCII armored keys. When attempting to trust ASCII armor keys, it will print error: bad signature on the screen.

mkdir --mode 0700 keys
gpg --homedir keys --gen-key
gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
gpg --homedir keys --export > boot.key

Now that we have a key, we can sign some files with it. We must sign:

  • a kernel
  • (if we have one) an initramfs
  • (if we wish to transfer control to it) an on-disk grub.cfg
  • grubtest.cfg in CBFS, if it exists
  • grub.cfg in CBFS, if it exists

You must provide a detached signature alongside each file. For example, if a file in a directory is named foo, and GRUB uses this file, an accompaning file foo.sig must exist alongside it.

Suppose that we have a pair of my.kernel, my.initramfs and an on-disk grub.cfg. We will sign them by running the following commands:

gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign grub.cfg

You must also do the above on any file that goes in CBFS, and insert it into CBFS, using instructions already provided on the GRUB CBFS guide linked above, earlier on in this guide.

Enforce GPG check in GRUB

The following must be present in grub.cfg, but please note that the background image used by GRUB is in the memdisk by default, not CBFS, so you might want to put it after the command that enables a background:

trust (cbfsdisk)/boot.key
set check_signatures=enforce

What remains now is to include the modifications into the Canoeboot image (ROM):

Please read and follow the GRUB configuration guide; this is the GRUB CBFS guide that was also linked above, earlier on in the article you're currently reading.

Install the new image

Now simply flash the new image, using the flashing instructions.

If you did all of the above steps correctly, your system should boot up just fine. Shut it down and wait a few seconds. If you screwed it up and the system is now unbootable, that's OK because you can use an external flasher; please read external flashing instructions

References