Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authenticated Boot and Disk Encryption on Linux (2021)

0pointer.net

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#41

Post by gradschool »

patrakov wrote: post #21
jest3r1337 wrote: post #10

Earlier quoted context omitted.

I have a laptop with a soldered in disk! Check mate mofo! All for our safety of course!

Hello, this is a security auditor. Could you please confirm items on the following checklist? 1. A BIOS password exists, with at least 8 characters, not based on a single dictionary word or keyboard-run sequence, and not easily guessable in other ways. 2. Booting an OS from any non-default device requires entering the BIOS password. 3. GRUB entry for bringing up the firmware configuration does not bypass the password…

I don't trust bios passwords. There's probably some jumper on the board that bypasses them or a previously planted hardware keylogger. I always boot off separately stored immutable rescue media whenever the machine has been out of my custody and checksum the whole boot device. Your move.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#42

Post by ruthmarx »

The way to do this IMO is:

Have the bootloader boot automatically into an encrypted guest OS, and have it obtain the key transparently from the TPM. This way the hard drive can not be read outside of the machine. The guest OS allows easy login, can be used to let people borrow your pc in a trusted way, and can also serve as plausible deniability when asked to log in in front of authorities or otherwise being intimidated or forced.

Then configure the bootloader to boot an alt OS or show a boot menu for a specific key combo, and enter a passphrase to boot into the real, 'hidden' OS.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#43

Post by ruthmarx »

transpute wrote: post #2

If you're interested in this topic, the 5th "System Boot and Security" LPC microconference" is on Sep 18, https://lpc.events/event/18/sessions/201/#20240918 Developing trustworthy Linux-based systems in an open-source way Common git repo for hosting Boot-firmware Accelerating Linux Kernel Boot-Up for Large Multi-Core Systems Leveraging and managing SBAT revocation mechanism on distribution level Using U-boot as a UEF…

> no more bootloader: please use the kernel instead

This had a post on HN before and I didn't find the arguments terrible compelling. I'm curious what security advantages they might be able to say exist though.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#44

Post by ruthmarx »

fsflover wrote: post #5

> the attacker takes the harddisk from your laptop while you aren't watching > You'll never notice they did that. Won't you be safe if you put a colorful nail polish to your laptop screws and take picture of its pattern? Then you regularly compare the actual pattern with your picture.

No. Anyone trying to tamper with your laptop that had that would do the same as you and take a photo to restore.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#45

Post by patrakov »

gradschool wrote: post #41
patrakov wrote: post #21

Earlier quoted context omitted.

Hello, this is a security auditor. Could you please confirm items on the following checklist? 1. A BIOS password exists, with at least 8 characters, not based on a single dictionary word or keyboard-run sequence, and not easily guessable in other ways. 2. Booting an OS from any non-default device requires entering the BIOS password. 3. GRUB entry for bringing up the firmware configuration does not bypass the password…

I don't trust bios passwords. There's probably some jumper on the board that bypasses them or a previously planted hardware keylogger. I always boot off separately stored immutable rescue media whenever the machine has been out of my custody and checksum the whole boot device. Your move.

Sorry, this is not a valid answer - you can checksum the boot device as much as you like, but I have not seen any procedure that ensures that you know the correct checksum. What could have helped you is not just a checksum, but a signature used with dm-verity.

What I do on my laptop is:

* BIOS password, of course. Note that this also prevents the attacker from resetting or turning off Secure Boot.

* Secure Boot enabled, with my keys only (no Microsoft keys).

* No GRUB, I use systemd-boot (part of systemd) and UKIs signed with my own key. Although, as I don't dual-boot, this might be an unneeded step. In any case, with Secure Boot enabled, systemd-boot does not allow editing kernel command line arguments at all and so cannot trick my UKI into doing anything else than what it is supposed to do.

* The main SSD partition is encrypted (with the passphrase that I have to type).

* The USB storage driver is not in the initramfs, so the storage device found by the initramfs is guaranteed to be my internal SSD.

* The Secure Boot keys are stored inside that encrypted partition and are used to dynamically sign new sd-boot releases and UKIs. I guarantee that I don't sign anything except UKIs that ask for my SSD password, and any shell-out possibility is treated as a bug.

* There is a separate set of keys for signing the custom rescue media, which is also a big UKI.

This way, the attacker cannot boot anything other than my UKI (first, because of the BIOS password, and second, because Secure Boot won't allow anything else), cannot obtain a shell by running something before I enter the password, and, therefore, cannot clone or overwrite my disk.

Note that this setup has also been criticized as insecure ("you don't use TPM, so you can't be secure, it's a theorem"), but I don't understand this argument.

As for the hardware keyloggers, you are, of course, right.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#46

Post by NekkoDroid »

ruthmarx wrote: post #43
transpute wrote: post #2

If you're interested in this topic, the 5th "System Boot and Security" LPC microconference" is on Sep 18, https://lpc.events/event/18/sessions/201/#20240918 Developing trustworthy Linux-based systems in an open-source way Common git repo for hosting Boot-firmware Accelerating Linux Kernel Boot-Up for Large Multi-Core Systems Leveraging and managing SBAT revocation mechanism on distribution level Using U-boot as a UEF…

> no more bootloader: please use the kernel instead This had a post on HN before and I didn't find the arguments terrible compelling. I'm curious what security advantages they might be able to say exist though.

IIRC from a presentation the main point behind NMBL is to not reimplement an entire OS in the bootloader like GRUB. Instead you should use the kernel with an Initrd instead and should kexec if you wanna boot into a different kernel. That way you only really need to take care of the existing kernel and userspace security.

The problem with that is that it starts to muddy the TPM PCRs (read: makes the PCRs that should be predictable not predictable) if the kernel gets kexec'd and it just makes the boot processes just needlessly more complicated. Not to mention when the kernel/initrd fails to boot you are kinda SOL since you can't really do any meaningful boot count logic if it fails as it could even be a faulty kernel and not even reach the initrd.

I also haven't been able to be convinced that NMBL is better than a simple EFI bootloader that chainloads a kernel.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#47

Post by thro1 »

fsflover wrote: post #37
thro1 wrote: post #35

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=18385507 ?

https://www.kicksecure.com/wiki/Malware_and_Firmware_Trojans...

(THAT, cite of tptacek, fulfilling someone's request, downvoted - with.. such empty*, hypothetical argument ?? - so far it's a libel - at least make some effort to proof otherwise in that case Mr FSFdiscreditor..

*"easier to hide backdoors" - so you don't need source to check the _real_ code - only more effort)

-

vs attack surface ? (having no reasons for powerful adversaries)

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#48

Post by NekkoDroid »

patrakov wrote: post #45
gradschool wrote: post #41

Earlier quoted context omitted.

I don't trust bios passwords. There's probably some jumper on the board that bypasses them or a previously planted hardware keylogger. I always boot off separately stored immutable rescue media whenever the machine has been out of my custody and checksum the whole boot device. Your move.

Sorry, this is not a valid answer - you can checksum the boot device as much as you like, but I have not seen any procedure that ensures that you know the correct checksum. What could have helped you is not just a checksum, but a signature used with dm-verity. What I do on my laptop is: * BIOS password, of course. Note that this also prevents the attacker from resetting or turning off Secure Boot. * Secure Boot enabl…

> * The USB storage driver is not in the initramfs, so the storage device found by the initramfs is guaranteed to be my internal SSD.

Do note, if you are using systemd-gpt-auto-generator with the DPS[1] it only searches for a root partition on the drive with the booted from kernel[2] (and any other DPS partitions are searched for from the drive with the root partition, so if you somehow specify a different drive than the one with the boot loader it will search on that different drive)

[1] https://uapi-group.org/specifications/specs/discoverable_par...

[2] https://www.freedesktop.org/software/systemd/man/latest/syst...

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#49

Post by rollcat »

bubblesnort wrote: post #34

This is of course a slippery slope argument, but not neccesarily wrong: I think systemd is moving a FLOSS operating system towards one that has source but comes in binaries. You get an initrd that's not built by you, tucked in a kernel also not built by you, runs the userspace from an immutable image also not built by you, which can be updated with binary deltas also not built by you, etc... This makes sense from the…

This mechanism makes perfect sense from the POV of every user (especially developers, who are often high-value targets) who isn't currently working on/actively contributing to low-level OS development. This is not a concern, unless your personal definition of computing freedom is equivalent with running Gentoo. If you want to tinker, there's always an escape hatch. Even macOS freely allows you to disable FileVault or System Integrity Protection (at your own risk).

Your freedom to tinker is not in conflict with my need to stay secure; in fact, when you're finally done with your tinkering, you too may appreciate the feeling of your data being secure against the most basic/common threats.

(I'm rarely in agreement with Poettering, but he's 100% on point here.)

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#50

Post by bubblesnort »

rollcat wrote: post #49
bubblesnort wrote: post #34

This is of course a slippery slope argument, but not neccesarily wrong: I think systemd is moving a FLOSS operating system towards one that has source but comes in binaries. You get an initrd that's not built by you, tucked in a kernel also not built by you, runs the userspace from an immutable image also not built by you, which can be updated with binary deltas also not built by you, etc... This makes sense from the…

This mechanism makes perfect sense from the POV of every user ( especially developers, who are often high-value targets) who isn't currently working on/actively contributing to low-level OS development. This is not a concern, unless your personal definition of computing freedom is equivalent with running Gentoo. If you want to tinker, there's always an escape hatch. Even macOS freely allows you to disable FileVault o…

I have no idea why having freedom would not include running Gentoo.

Gentoo, as a matter of fact, offers lots of freedom. Its package manager has built-in capability to distinguish licenses. You can choose between systemd or openrc. Musl or glibc. You can disable all sorts of configure options you don't want or need. You can use it stand-alone or inside another distro. You can specify cpu flags for the compiler globally and per package. You can drop in your own patches for any package (and yes, I use that too). You can more easily modify just about anything in the entire system than most distros.

Using Gentoo lets you build a useful system for whatever you do, from sources or binaries, tailored to your needs, without the burden of having to learn all of the different build systems, their dependencies, and weird quirks you'll come across as a package maintainer of any distro. Ever looked at the rpmspec of things you use? Or the patches in a Debian source package? Those details are all taken care of, but with portage still customizable on a high level.

Post reply on HN