Safeboot: Booting Linux Safely | Hacker News Reader

Safeboot: Booting Linux Safely

safeboot.dev

197 pointsthudson54 comments

I really like the philosophical approach here, even if it's too finicky to put in practice today. I'm really sick of everything being made "secure", when in fact the "security" is for someone other than the legitimate user of the thing. Phones, laptops, physical security systems, cars, the list goes on.

There was a post here yesterday (https://news.ycombinator.com/item?id=23149771) about the (in)security of Linux, but the primary purpose of an OS is utility, not merely security. The leadership of the Linux project made very smart analyses of what priorities come first. Despite there being billions of insecure old devices scattered about, running old kernels, I think the kernel authors made the right call.

The problem rests with the manufacturers who abandoned support for those devices and left no escape route for users to update the kernels themselves. Most disgusting are these phone and car manufacturers, and apps, which have enabled wholesale spying on users for many years now. These devices are literal bugs, reporting realtime locations, conversations, and who knows what else to Big Brother.

Its a pleasure to see that some people still care enough to make the world a better place, in a way I can understand.

> I'm really sick of everything being made "secure", when in fact the "security" is for someone other than the legitimate user of the thing.

It's less binary than that for me. Yes, the same technologies that keep my data secure also act as a buttress against jailbreaking. But people who want to jailbreak can simply choose less-secure devices, while I would personally not trade that security for greater hackability. There are other, lower-risk devices than phones and cars that I can use for that.

Apparently your threat model doesn't include governments and large corporations, who have done more enumerable harm (e.g. through the military-industrial-information complex) to people than small-time crooks ever have. Sometimes it seems more people want to live in prison (or a gilded cage), than in regular civilian life with all its attendant dangerous freedoms.

The point of the OP is that users can and deserve to have the reliability that cryptographically-secure boot systems provide, without the Big Brother backdoor.

I appreciate the conversation.

> Apparently your threat model doesn't include governments and large corporations…

It's a consideration for sure, and it's why I use Apple devices instead of Google-powered ones, don't use Facebook, use DuckDuckGo as my primary search engine, etc.

I'm not worried about Apple selling my information (for now, given their current business model) but my network provider is absolutely doing this regardless of device. Given that, what actionable recommendation is even possible?

VPN?

It's a tough one, for sure.

Personally, I'm looking forward to a pinephone. I'm moving towards asynchronous communications, and leaving my phone at home, or in a "faraday pouch" (made of [0]) on airplane mode.

Networking is done through an elastic ip vpn that forwards to a known host, so web sites that I want to use, but I don't want to trigger the captchas and 3FA stuff, see the same user-agent and IP address. I also have many "disposable" phones, that I use on projects that require Google Hangouts or WeChat. Recently I had to upgrade my daily driver phone, and I haven't installed Lineage yet. It's a slog, so I can totally understand why people would simply accept what's readily on offer.

At a basic level, my thinking is that "is this better for me?". That is, how are these capabilities[1] going to be used, in my favour, or against me? Since I have previously been dragged into a large investigation (regarding someone else operating under a false identity), and have had to get various clearances from various governments to work on projects (which is more common than I would naively think), the approach that I take is to appear unremarkable.

In the past, when leaving countries that require exit visas (like China, Israel), I was shocked at how much information they had on me, and revealed in the course of the exit interview. But I have to assume that Anglo countries, if anything, have more advanced technical means at their disposal, but decline to use them unless the target is juicy enough. So the reasonable approach is to do my best to make my pattern "normal" and "unappealing" -- maximizing my benefit from these tools, and minimizing the risks of false associations and accusations.

[0] https://www.sparkfun.com/products/retired/10056

[1] https://www.theverge.com/2013/8/1/4580718/fbi-can-remotely-a...

IMO the industry has made this into a false dichotomy. I want both security and hackability, and I don’t believe for a second that wanting better security means we should have to give up control of our devices.

I don't see the need for a trade; SIP for example is an Android feature (I'm surmounting your "less-secure" to "Android"); why can they not support replacing the manufacturer keys, just like my UEFI laptop, so that I can modify my OS, build a custom kernel, sign everything and relock the bootloader?

I think we know the answer, and that is; the attitude towards things like mobile phones being different to that of a laptop; we don't really "own" or phones in the same sense and if shouldn't be that way.

"I'm really sick of everything being made "secure", when in fact the "security" is for someone other than the legitimate user of the thing."

There must have been some groundswell movement amongst users all demanding that the boot process be made more "secure". There must have been well-publicised cases where "bad guys" were hijacking the boot process.

Perhaps different people have different definitions of "secure". If some third party, including the seller, has control over access to the computer or what I can run or disable on it after I purchase it, then I do not consider that computer to be more "secure". I just consider it to be less useful and less trustworthy to use with any personal data.

> There must have been some groundswell movement amongst users all demanding that the boot process be made more "secure".

There wasn't. Users want security in general but most people would not even realize it if a boot process was insecure nor would they understand the implications.

> There must have been well-publicised cases where "bad guys" were hijacking the boot process.

Yes. The "bad" guys are the people running "unauthorized" software on computer hardware. Governments and corporations would very much like to restrict what users can and can't do. Widespread cryptography is viewed as an existential threat to law enforcement and intelligence gathering. Companies enjoy owning their users and being in a monopoly position with regards to the software market for their devices. So we get systems which control the user instead of systems controlled by the user.

This is a great analysis.

When I was a kid, I used to wonder what the difference was between soldiers and police. I was told that soldiers were meant to protect the State from its enemies, whereas police were meant to enforce the rule of law. I was also told that when soldiers were used for policing, everyone tends to turn into an enemy of the State.

It turns out, this view is correct, but omits that police tend to become soldiers for the State anyway. The ones that actively serve the citizenry's best interests seem to be far and few between.

There isn't that much difference when it comes down to it.

https://en.wikipedia.org/wiki/Military_police

Yes.

In theory, "military police" enforce military law and are responsible for policing the army, navy, and so on. They're usually limited in their ability to enforce civilian law. In the USA, it's prohibited under the Posse Comitatus Act and the Insurrection Act, but this isn't universal by any means.

Slightly unrelated:

I currently have a custom platform key, packet everything I need for booting into a single image (signed with the custom platform key) and everything else is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is inserted via keyboard on boot, which is not to everyone's liking but is what I want.

It's not really hard to setup (on arch Linux) and works like a charm. ;-)

Through the drawback is that the initRamFs is only protected by the signature/secure boot but not encrypted and combining it with some other boot related setup can be less straight forward then under a "boring" setup.

I.e. some of the thinks this project promises are already possible now, just not streamlined. Which is why it's nice to have such a project.

What's the disadvantage of not encrypting your initramfs if it's protected by a signature?

That was exactly my motivation: there are tons of guides for setting up UEFI SecureBoot platform keys, yubikey tokens, TPM disk encryption, dmverity, etc, but all of them seemed to involve "type hundreds of commands with no mistakes and hope that your system still boots afterwards". It felt to me that each program represented a low-level library function that needed to be linked into a high-level tool to handle the common cases for most users.

Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.

One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.

If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.

There's a way to encrypt the boot partition and have GRUB ask you for the boot partition key, but you're limited to LUKS1, and the decryption process is slow as molasses, since it's implemented inefficiency directly in the GRUB code, because the Kernel's faster code isn't loaded yet. It's also probably full of side channel leaks. Signing the kernel and ramdisk is probably the better option...

What's your defence against an attacker with a few hours of physical access meddling with whatever comes before you typing the decryption key, such that you're actually typing your key into a program controlled by them, which then decrypts your filesystem image, inserts its own malicious code into some irrelevant kernel module, then boots the system as normal?

> fTPM tampering is out of scope since the ME is the root of all trust in the system

I'm wondering about this assumption. Hasn't the ME previously been shown to be fairly straightforward to exploit?

ME has had exploits, but it has also had patches.

I think they refer more to the "technical" term "root of trust" then to weather or not persons trust it/it has had security vulnerabilities.

As long as there is choice (e.g. between fTPM and dTPM) then it's up to the eye of the beholder to pick appropriately. An fTPM is better than nothing, but discrete TPMs have certifications.

If you're interested in this kind of thing, Invisible Things Lab are really worth checking out https://theinvisiblethings.blogspot.com/2009/10/evil-maid-go...

So what about this:

- Copy GRUB, bootlines for your system, your kernel and initrd to a WORM media like a bootable CD-ROM.

- Boot using CD-ROM.

- When boot completes, remove the CD-ROM.

Now you can't attack my boot kernel or boot process because I've just physically separated it from the system and taken it with me. Even if it was there, the media is read only so you can't modify it.

If I need to upgrade, I need to burn a new CD. CDs are cheap.

Using actual CDs would be impractical for many users, but a parallel could be implemented on a system with micro-SD card readers supporting removeable media and a physical read/write or connection switch. Which, if we're talking about physical switches for camera and mic, why not boot files?

Hmmm.

This implies that you have set your boot order to CD-ROM first, so anyone can - say - boot their own system on your machine from CD and either access your data or make a dd-copy of your disk and look at it later.

You need also to password protect your BIOS so that first device in boot order is hard disk and settings cannot be changed (without BIOS password).

Depending on the BIOS this change in booting order could be possible at boot time (providing the password) or a reboot would be needed.

> You need also to password protect your BIOS so that first device in boot order is hard disk and settings cannot be changed (without BIOS password).

You also have to make sure your BIOS can't be reset by removing the battery, doesn't have some administrative bypass or even a reset jumper. I've even seen a BIOS that reset to default boot settings when you remove all disks - and then gleefully boots from any attached USB disk.

Yes, and additionally we will also need a machanically safe case, as - even if the boot order is set to hard disk, it is not modifiable (without password) and the BIOS resists removing power and battery, noone would prevent you to detach the hard disk and either replace it with your own or more simply steal the hard disk and have a look at its data without hurries.

Security is tough.

I’m guessing this setup makes sense with encrypted disk, that way, since decryption keys are on the CD, you can’t access the files without it.

Well the way it works in Linux is a user-space program in the initrd (which is the initial rootfs) will ask for password to unlock LUKS-encrypted rootfs, and then the initrd will mount the real rootfs at that point.

Since I have a physical trusted copy of that initrd with the kernel and bootloader that is safe.

DD-ing the whole drive is something I assumed Secure Boot doesn't protect as someone could remove the drive and do the same. Even if the drive, eMMC or flash is soldered to the board there's some way to get to it (desolder, JTAG pins, etc.)

This actually sounds like good actionable advice for a semi-technical person like a journalist.

Still leaves you vulnerable to bios compromise (e.g. get some malware running in SMM before your kernel), but that can be addressed by soldering the bios WP pin low and dropping some epoxy over the laptop case screws.

Edit: There are some SPI chips that have a write protect fuse that you can blow, leaving your bios in a known-good state. [1] pdf page 7.

[1] https://cloud.3mdeb.com/index.php/s/PBfAzZZQYcj3xbs

My understanding is MicroSD “hardware” switch triggers a software based switch that not enforced by the hardware; that is, it is not designed security.

Even a “read only” CD-ROM if not verified on boot for tampering — might contain an attack, including: to just disable the disk from booting, among other things.

Does anyone know if anything similar is possible with Windows? I am interested in the idea of signing the bootloader with your own keys to prevent other system images from being used on the system. It seems like such a system would provide much better anti-theft guarantees than existing solutions like CompuTrace/Lojack.

Isn't that what Bitlocker and Secure Boot do essentially?

https://docs.microsoft.com/en-us/windows-hardware/design/dev...

In its typical configuration, Secure Boot can't provide any anti-theft guarantees because an attacker could just replace the contents of the disk with a new Windows installation and the workstation would be usable for them.

Secure Boot as it is configured by Windows only prevents malware from inserting itself into the boot process, since all Windows installations use the same signature. Bitlocker only prevents attackers from accessing the data on the disk, not from using the workstation in general.

You can usually lock the whole system with a boot password. In the case where the attacker replaces the whole disk, or whole disk image with another Windows image, you can also add your own keys and sign the image or individual boot files.

Hmmm, is it theoretically possible to sign the Windows bootloader (?) with your own custom keys to ensure that someone couldn't just fire up a stock Windows image? Though I'm not sure what sort of management challenges that would present if Microsoft ever decided to update their bootloader.

Looking at the Microsoft documentation, doing this with SecureBoot could be pretty complicated: https://docs.microsoft.com/en-us/windows-hardware/drivers/br...

I havent tested personally but this seems to suggest that you can't re-sign the bootloader: https://docs.microsoft.com/en-us/previous-versions/windows/i...

> "Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows boot components verify the signature on each component. Any non-trusted components will not be loaded and instead will trigger Secure Boot remediation."

Plus, you would need to add some kind of check to verify that it's actually booting your image, or else the attacker could just copy your bootloader files.

> In its typical configuration, Secure Boot can't provide any anti-theft guarantees because an attacker could just replace the contents of the disk with a new Windows installation and the workstation would be usable for them.

What's preventing an attacker from resetting the secureboot settings? You'd need some sort of activation scheme like on iOS.

I had originally hoped to enroll signing keys in the firmware of my X1 carbon until I read this post[1] on reddit claiming it has the potential to brick the laptop, and so far I haven't found an official statement from Lenovo claiming otherwise.

[1] https://www.reddit.com/r/thinkpad/comments/epadb5/psa_dont_i...

Sounds like what the T2 chip does on MacOS, which I also found interesting:

https://duo.com/labs/research/secure-boot-in-the-era-of-the-...

Anyone interested in this might like keylime.dev - its open source remote boot attestation platform.

If every Linux user would boycott AMD to release their source, then we could have libreboot: https://libreboot.org/amd-libre.html

ME vs PSP isn't much of a choice. Of course POWER might be an option eventually, but isn't for most of us currently.

Boycott AMD, and obviously Intel [0]. Doesn’t really leave a lot of options.

[0] https://libreboot.org/faq.html#intel

Well there is POWER[0], not that it's a very affordable choice, the cheapest motherboard + cpu costing $1,732.07

[0]https://www.raptorcs.com/content/BK1B01/intro.html

Is ARM an option? I know in practice many ARM systems rely on blobs, but it's not clear to me that that's universal.

There is nothing like "ARM" in the market.

There is CPU/SoC X by Y, built on top of a license from ARM.

So you would have to boycott N companies instead of just AMD & Intel :( And even more so, since all their customers are EOM that are happy to sign NDAs.

Decent blob scarce arm option: https://libre.computer/

There are ARM systems that don't need blobs. Whether they are useful to you is a different question. An example is the iMX line from NXP.

It looks like that stuff was hot 3 years ago. Is there a newer (more likely to pay off) push? I'd happily tell AMD that I'm in the market for an expensive new system and I'd instantly go with Ryzen if it were open. As it stands now I'm leaning Intel because it's the devil I know.

I don't understand. Intel has ME, AMD has PSP, neither makes any particular effort to support libreboot (although I'm pretty sure coreboot can work with both if the manufacturer wants, because Chromebooks do that). Unless you believe that Intel is more open, why would you prefer it? It appears to me that they're equally security-unfriendly, but with AMD at least winning on price and performance.

> It appears to me that they're equally security-unfriendly, but with AMD at least winning on price and performance.

I agree (although I'm not sure price and performance is significant enough to matter to me), the only reason I would go with Intel is that it's what I've been using for the last 20 years, and it's what I know. I had an AMD one time (late 90s/early 00s) and had a lot of problems with it. I know AMD today is much different than in the past, but I'm still wary whe the investment is one I will need to use for 5 to 10 years.

But if AMD went libre, I'd jump ship.

Or, instead of boycotting, work towards sensible laws for obliging software/hardware providers to provide sources.

But if they release everything libreboot want's wouldn't that potentially undermine DRM (e.g. webdrm pluging as used by netflix)?

I mean I'm not a fan of DRM but then undermining it might cause browsers on Ryzen to no longer be able to run Netflix and similar.

While I guess many people on this site wouldn't care too much it's not profitable for AMD.

But then there should be a way to have both. The case which don't need/want DRM and can have a complete libre system and the case which needs DRM for whatever reason and sadly can't go libre.

POWER has Ultravisor.

Reply on news.ycombinator.com