Would it add security to set a GRUB password if HDDs are encrypted and UEFI settings can be opened anyway?

Question

So I'm using Debian 9.1 with KDE and have my hard drives encrypted. Now I'm wondering whether to additionally add a GRUB password as described here.

Would that make sense? As the hard drives are encrypted nobody should be able to boot/access them right? Also before the GRUB bootloader starts the UEFI settings can be accessed even before entering the GRUB password.

However, this page also lists "Preventing Access to the GRUB Console" as one of the reasons to set a GRUB password. And maybe there are some changes / configurations that I need to do for it to add security?

Should I instead only set a password on my UEFI settings maybe? Or are bios passwords entirely redundant in my case?

Answer 1

Adding grub password is needed to protect the boot sequence, but protecting the boot sequence only makes sense if you protect the entire boot sequence, in other words if you enable grub password, you should also enable UEFI password and vice versa. It's kinda pointless to set one but not the other, so to answer one of your question, no, it's not redundant.

When you have Secure Boot, each component in the boot sequence should cryptographically verify the image loaded for the next boot component. In other words, UEFI loads and verifies a cryptographically signed GRUB image (using UEFI Secure Boot), and GRUB loads and verifies a cryptographically signed Linux kernel/initrd/drivers. When you have the entire chain verified using Secure Boot, then the only vulnerability left is if the attacker replaced the motherboard/Boot ROM, this is a physical attack that can be delayed or made difficult by using physical security measures (e.g. casing/rack locks, security cameras, security guards, tamper evident stickers).

There's little sense in encrypting /boot, but there are good reasons to cryptographically sign the files in /boot to prevent boot hijacking). Secure Boot in UEFI and GRUB are part of the solution to booting an operating system without a cryptographically signed boot sequence; adding boot passwords prevents people from making unauthorized changes to UEFI/GRUB settings or booting unsigned systems from UEFI Shell/GRUB Shell.

Answer 2

Your user data on your hard drive is encrypted (and MACd) to prevent unauthorized reading, and to detect modifications. Latter part means an attacker could wipe your whole disk and write own stuff there, but replacing single files etc. with something sane is not possible.

If /boot is encrypted too ("if", because many instructions leave /boot unencrypted), what for? To prevent reading Grub (it's a known software)? No. To prevent malicious modifications? Maybe, but nothing stops me (let's say I'm the attacker) from overwriting the "whole" Grub partition with my own malicious bootloader (or supply a second disk with an own bootloader). I don't know your own files, but I know how to make a /boot partition. ... Meaning, you lost. My own bootloader can take over the computer as soon as you turn it on, and spy on your HDD key later.

About GRUBs configuration console, preventing access without password does make sense in a specific situation: The attacker can not access the hard drive. Think ATM. (If he can, as said above, the password is useless too.)

Similar for your UEFI settings password: If I can access the hardware (replacing mainboards, flashing chips, ...), it's completely useless.

Bottom line, what do you want?

• Protect your files from being read, but if your computer gets stolen you can't ever trust it anymore (even if you get it back)? Keep the disk encryption, and ignore the rest.

• Protect your computer from being stolen and/or modified? Use all and put it into a safe, with a radiation shield and much more.

• Somethine else? Impossible.