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...<p>This makes sense from the perspective of making a kitchen appliance for the home consumer market. It makes no sense at all from the perspective of making a Unix-like operating system with four freedoms from scratch and ensure it stays that way.
If you're interested in this topic, the 5th "System Boot and Security" LPC microconference" is on Sep 18, <a href="https://lpc.events/event/18/sessions/201/#20240918" rel="nofollow">https://lpc.events/event/18/sessions/201/#20240918</a><p><pre><code> 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 UEFI payload
Measured Boot, Secure Attestation & co, with systemd
Secure Launch - DRTM solution on Arm platforms
no more bootloader: please use the kernel instead
OF != UEFI</code></pre>
But.. isn't true that some Intel SSD Hardware Encryption is not (known to be) broken so far (unlike Samsung, WD, Crucial etc.)?<p>( <a href="https://www.tomshardware.com/news/crucial-samsung-ssd-encryption-bypassed,38025.html" rel="nofollow">https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...</a> <a href="https://community.wd.com/t/what-do-you-think-of-the-security-flaws-in-the-western-digital-security-encryption-on-our-harddrives/172354" rel="nofollow">https://community.wd.com/t/what-do-you-think-of-the-security...</a> <a href="https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/" rel="nofollow">https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-...</a> <a href="https://techreport.com/news/256-bit-aes-encryption-broken-in-sandforce-ssd-controllers/" rel="nofollow">https://techreport.com/news/256-bit-aes-encryption-broken-in...</a> <a href="https://security.stackexchange.com/questions/134564/how-secure-is-hardware-full-disk-encryption-fde-for-ssds" rel="nofollow">https://security.stackexchange.com/questions/134564/how-secu...</a> and some Defcon(?) files I can't find now - no success with Intel ? )
<i>> Instead of stealing your laptop the attacker takes the harddisk from your laptop while you aren't watching [...] makes a copy of it, and then puts it back.</i><p>I've never understood why people keep making this incredibly weak argument for secure boot.<p>Secure boot makes sense for a college computer lab, where any disk encryption is better than nothing, and you can't give everyone the password or it'd defeat the point.<p>Secure boot makes sense if you're a Microsoft-only company, as it's a closed-source OS anyway and Microsoft have the code-signing keys. It means your users only have one password to type in - and helpdesk can reset it remotely if a user forgets.<p>Secure boot makes sense if you're making something like an xbox or tivo where you want disk encryption but you can't give the owner the password, as they're the adversary you're trying to protect against.<p>And yet people instead ignore these benefits, and go for this spy thriller nonsense as if people are going to be crawling through the air vents and abseiling from the ceiling to interfere with my computer? If you're going to pretend to be James Bond you'd better also be learning ballroom dancing, kung fu, skiing and foreign languages.
I'm surprised that the author doesn't mention Pureboot [0] or even Heads [1], the most user-friendly [2] way to use TPM on Linux and authenticate the boot process along with /root, /boot directories.<p>Also, there is no Microsoft involved in my laptop, i.e., the author's statement<p>> Microsoft's certificates are basically built into all of today's PCs<p>is wrong. I enjoy the coreboot with Heads on my Librem 14 with my own keys.<p>[0] <a href="https://docs.puri.sm/PureBoot.html" rel="nofollow">https://docs.puri.sm/PureBoot.html</a><p>[1] <a href="https://github.com/osresearch/heads">https://github.com/osresearch/heads</a><p>[2] <a href="https://puri.sm/posts/pureboot-101-first-boot-first-update-and-detecting-software-tampering/" rel="nofollow">https://puri.sm/posts/pureboot-101-first-boot-first-update-a...</a>
The way to do this IMO is:<p>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.<p>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.
Lennart is technically doing good work.
While his tools are less complicated than the current hilariously convoluted standard boot process, they are still too complicated to use well.<p>He also misses the point with the attack scenarios.
If you luks encrypt your data and choose a good passphrase, the brunt is done against theft.
Protecting against bad passwords is futile in the long run. (Will elaborate if requested.)
That someone images your drive for offline bruteforce or manipulates your boot binaries is rare.
The true benefit of signed boot chain is to have security patches work reteoactively, "compromise recovery".
Automated attacks and malware from the internet side are way more common.<p>Imagine one of your daemons is compromised. As long as it does not escalate privileges, it can only gain persistence via corruptable data files or config accessible to itself.
Now a patch comes along that closes the hole that reinfects the daemon.
The malware will not start on daemon restart.<p>With signed booting you can bring that to the kernel and root.<p>Signed booting with rollback protection into a known good state.
As long as the malware is not part of that system it won't run on launch.<p>But who signs my stuff, especially my own scripts and automation?
Me of course, if I had good tooling.<p>If that became normal malware would just steal the key.<p>A TPM or other keybearer device lets you conditionally unlock a signing key.<p>So to sign, you can boot your system into a runlevel / target / ... that does not run auxiliary scripts from writable locations.
If that state is measured by the TPM, you can sign.<p>With good enough tooling this is workable.<p>If implemented well, this even helps maintenance of the system.<p>In the state of things now, its a horrible convoluted mess that doesnt give extra security but 10 more points at which you can break your boot.<p>+ UEFI itself is again a complexity monster full of holes on very many machines.
The whole x86 preboot stack amd or intel is a horrible complexity monster.
> the attacker takes the harddisk from your laptop while you aren't watching<p>> You'll never notice they did that.<p>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.
Is this for real? Is the initramfs not signed and authenticated? if that was the case it would be a very serious and obvious flaw I would have thought.