Brave New Trusted Boot World | Hacker News Reader

Brave New Trusted Boot World

0pointer.de

63 pointsfreedomben31 comments

Previously: https://news.ycombinator.com/item?id=33340866

I'm not dang, but let's see if we can not turn this thread into yet another referendum on systemd.

Starting off by directly referencing a dystopian novel and then outlining a plan towards such a dystopia? They're not even trying to hide it now and have already infected Linux.

If you truly value your computing freedom, stuff like this should seem deeply unsettling and scary. The only way out is to fight strongly against this growing wave of techno-authoritarianism.

Embrace, extend, enslave.

We already have remote attestation in Android, and it basically killed a range of reasons why one would ever decide to unlock their bootloader or root the device. Yes, doing this to PCs should be scary.

So that's why i cannot uninstal spyware on my child's computer ?

This comment mentions some non-dystopian uses of remote attestation:

https://lwn.net/Articles/914323/

The one about leaving your laptop in the hotel and then the laptop being able to prove to your phone that the laptop hasn't been tampered with, is pretty compelling.

Of course one can envision many handy uses for remote attestation that would benefit individual users! Web 2.0 also had many technical advantages over local software - there are certainly reasons why it got adopted.

But focusing on positive uses is naive and fallacious - the criticism is based on the downside of the inevitable negative uses when the device keys are recorded by manufacturers to create a root of trust that arbitrary third parties can abuse. The problem is that the technical capability also puts those end users at the mercy of large commercial actors specifying that the user's computer is "secure" from their centralized-corporate perspectives. Over time, that will inevitably ratchet into ever-more locked down computing forced onto end users. You can already see this dynamic with "SafetyNet" on Android, which destroys users' ability to exercise the purported Freedom of Android regardless of the source code being available.

The problem is that a secure, verifiable computing environment is also important for your privacy.

If you use this system with free software components, the dystopia won't materialize. It's the lack of transparency with proprietary components that causes problems.

The problem is not the secure boot itself, but how the designer, primary enforcer, primary CA and key control authority of said system is the worst imaginable candidate on the whole universe (and possibly beyond).

Remote atestation? Why ?

For example, I use my SIM embedded digital signature on my mobile phone. Being able to verify that it’s not altered with, and being able to verify this state with a remote secure entity sounds nice.

Assuming you can select/provide the baseline state to be verified against, I fail to see how this is harmful.

Of course this can be used to force “desired configuration” on anyone, but this is a social problem rather than technical.

> Of course this can be used to force “desired configuration” on anyone, but this is a social problem rather than technical.

No, remote attestation as laid out with escrowed keys is a technical vulnerability through and through, which upends the existing social power relationships. You wouldn't write off the installation of police surveillance cameras in your house a mere "social problem" even though you could still organize politically to create restrictions on their use. Rather the social aspect only becomes an issue due to the addition of the technical ability (vulnerability).

Key-escrowed remote attestation is fundamentally a rejection of the longstanding concept of mediation by open protocols. Right now, the demarcation point between independent parties is what goes over the wire. On my computer I run software that represents my interests, on a server a company runs software that represents their interests, and we temporarily cooperate by communicating in a well-known manner.

No matter how powerful the remote entity is, they still cannot force me to run software contrary to my interests. Sure they can make it harder by only shipping proprietary executables and obfuscating the protocols, but ultimately if the interaction is important enough then it can be reimplemented in Free software to appropriately represent users' rights.

Meanwhile, key-escrowed remote attestation lets each party insist on what software the other party can run while they're communicating. Of course, an individual user will have zero negotiating power to affect what software a company is running, just as end users have zero negotiating power to cross out objectionable terms in those blobs of legalese shoved at us. Rather, commercial services will be provided on the same take-it-or-leave-it basis, then with the addition of mechanically enforced conditions of only running specific software. Once this is easy enough to do that insisting upon it will only marginalize a small number of customers, companies will reflexively adopt it - remember, "security" departments love checking boxes.

Facilitating key-escrowed remote attestation on Free operating systems undermines our hard-won freedoms, and splits the Free software market-power bloc. Right now, a basic binary-distributed Firefox-on-Ubuntu user appears essentially the same as a user who has modified their software. The basic Ubuntu user is happy to be running Free software, but if we're honest it's more of a theoretical/upstream concern until they start hacking. However, if Ubuntu gets the vulnerability to attest exactly what software it's running, then that's a stark difference between them. The basic Ubuntu user won't notice that they have lost some freedoms they weren't using, whereas the smaller contingent of people that wish to run modified software will have directly lost FSF Freedom 1.

The only way to keep remote attestation honest is for there to be no privileged signing keys embedded by the manufacturer. Ideally the end user would prompt their generation, but if initial keys are created at the factory then nothing about them (including the public identity) must be recorded.

Then there would be no way for a random third party to tell if you are running on bare metal hardware, or within virtualization with mock attestation. True owners of the hardware can still record the signing keys and build their own trust relationships. But no centralized databases that would allow arbitrary third parties to trust that users' own hardware is undermining user interests.

> Assuming you can select/provide the baseline state to be verified against, I fail to see how this is harmful.

Okay, but that has 0% chance of being what happens.

Sure, it's important that I can verify what my computer is running. But it's also important that the MAFIAA et al. cannot. If there were some way of guaranteeing that attestation could only work for the owner, then I'd support it, but if that's not possible, then I'd rather it not exist at all.

The post is excellent.

However, if one uses a UKI, is initrd as useful as it was? After all, you could ditch modules and compile directly to kernel, and there'd be no space difference whatsoever. Perhaps we could make things simpler if initrd wasn't needed for most systems.

I've been booting initrd-less systems for a long time. It's quite doable but requires a different setup than the default.

Can you do e.g. full disk encryption that way? (And, crucially, do you get a semi-graceful failure mode if the disk encryption fails somehow? Similarly for e.g. network filesystem as root). I can certainly see the value of simplification, but being able to run some kind of userland before you've got your main filesystem up and running has a lot of use cases.

I use fscrypt, my typical threat case won't be able to break it, and I think the failure mode is more graceful (you can set up alternate methods for decryption, I use a backup password). FDE should be possible with the right kernel support, but not sure this exists today.

Would like to hear more.

Booting uses PARTUUID to find the right boot partition (there's a systemd standard for finding the right partition automatically if the right UUID is set, but nothing seems to actually use it? I did set up the right UUID from the standard just to document things).

Encryption is via fscrypt, which isn't as good as FDE - not sure if FDE is impossible here, but I think this is enough security for the typical adversary. If a three-letter agency was a threat, I'd be toast anyway.

Custom kernels: Module loading is disabled - I've enabled everything that a normal install would load and added some netfilter things. Firmware is compiled into kernel too. Of course custom key is used for secure boot.

Neat thanks. Was just setting up a new system and was kinda dismayed initrd is still a thing.

Yes - the idea is that modules can be pre-built into a set of add-on images that can be independently signed, and the UKI can pick those up. That way you still only install the module images that are required into the boot partition, rather than having to include all modules in the initramfs.

Building into the kernel instead of using modules is not perfect because it increases RAM usage when you don't use certain modules compared to having them loaded on demand.

Initrd is as useful as it was before. It is just combined with the kernel image. You can still ignore the bits of advice from that blog post, and generate the initrd using whatever tool that you want, exactly as before. What is added is just one objcopy command to combine the kernel, the initrd, and the command line into one blob (UKI) that you can boot. You can even sign it with your own Secure Boot key, and it will still work, and be more useful than its components, because now your initrd (reminder: built according to whatever method you want) is cryptographically verified.

How much does it affect playing on your own hardware? I worry that we are increasingly entering a world where it becomes impractical to install a niche hobbyist OS directly onto a hard drive.

They are not going to forbid installing niche OSes because it'd look bad and they can do better.

Today you can't use banking app in a rooted Android, you can't watch high resolution licensed content in your linux PC, you're at the whims of rootkits disguised as anti-cheat frameworks if you wanna do online gaming.

Tomorrow you'll be required to use signed browser binaries by selected vendors running on a signed OS unlocked by TPM loaded with your ID card for joining a video call for a job interview or something.

Did you say your niche OS? Sure, you can view their support forums or wherever other hobos are hanging out for leisure without any of that.

> Boot chain is typically Firmware → shim → grub ...

Is this really true? Or just when using Red Hat systems? I don't know too much about the boot chain, but I always thought that after the ROM stage, usually GRUB would take over directly from the UEFI.

When using UEFI secure boot you typically boot into the shim (signed with a certificate OOB-trusted on almost all PCs), which verifies the integrity of grub and then passes on control to that.

Without secure boot, I don’t think there is any need for the shim, but if it’s still used or not in those cases, I do not know.

Shim is there for Secure Boot. Microsoft refused to sign grub (GPL-3), but signed the shim (BSD-2), so shim has its own key store and verifies grub signed by respective distros.

If you don't use Secure Boot, UEFI firmware can boot directly to grub.

I see, thank you and the others.

You can technically do away with GRUB or similar, too, and have the UEFI boot directly the kernel+initrd image via efistub.

This will, of course, not be signed by MS, so if you use SecureBoot, you need to handle your own signing. Set up is not automatic AFAIK, but once you've created your keys, signed MS's boot key (if you need dual boot), replaced the UEFI's key with yours and set up your package manager to sign every kernel update, everything works well enough. Haven't had a single issue with this in 4 years of running on "enterprise" HP laptops.

Isn't this exactly the tivoization that RMS warned us about?

Or just copy Microsoft's design for BitLocker, and adapt it to Linux. They solved all these problems a long time ago.

Reply on news.ycombinator.com