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.
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.)
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.
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 != UEFIThis 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.
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.
( https://www.tomshardware.com/news/crucial-samsung-ssd-encryp... https://community.wd.com/t/what-do-you-think-of-the-security... https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-... https://techreport.com/news/256-bit-aes-encryption-broken-in... https://security.stackexchange.com/questions/134564/how-secu... and some Defcon(?) files I can't find now - no success with Intel ? )
If yes: please share.
If not: why not?
Thanks!
I've never understood why people keep making this incredibly weak argument for secure boot.
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.
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.
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.
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.
And we want this to be default for users? I like lennart's work, but this further complicates things A LOT. What happens in case of hardware failure? If parts of the drive becomes unreadable and you need to retrieve as much data as possible? Oops you forgot to enroll your recovery key...
What will people do to avoid data loss and to avoid learning how the system as a whole works? Create backups and those will be stolen by nefarious entities instead.
Linux is mostly not so complicated. But this latest post... if this becomes the norm, oh god, unnecessarily complicated way to protect against imaginary threat. How widespread these hard disk removals are in the wild? I know maybe 1 case in the last 10 years that was publicised.
People are paranoid about things they can't control and don't understand at all, and these measures calm their nerves. Whew, I'm so important, my data is so important, now I'm protecced. While the ones who really want your data already waltz in anytime they want into your system and you can't do shit against it, because you are expert at max in one domain. The threat modelling already tells you that the compromise you have to take is that there are peepz you can't defend against.
That has nothing to do with secure boot. You won't lose access to the drive, the issue is that you want to mostly not use that recovery key all the time.
Quick survey. How many of you cyber security people out there "would not" be able to tell if someone broke into your house? :-) I'm betting a lot.
Yes, the author is actually working at MS: https://en.wikipedia.org/wiki/Lennart_Poettering
CBP and other countries' "border control" routinely forces people to let them examine their devices. That's bad enough, I'd at least be happy if there were an attestable way these pigs don't install malware on peoples' devices.
Also, there is no Microsoft involved in my laptop, i.e., the author's statement
> Microsoft's certificates are basically built into all of today's PCs
is wrong. I enjoy the coreboot with Heads on my Librem 14 with my own keys.
[0] https://docs.puri.sm/PureBoot.html
[1] https://github.com/osresearch/heads
[2] https://puri.sm/posts/pureboot-101-first-boot-first-update-a...
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.
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.
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.
With signed booting you can bring that to the kernel and root.
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.
But who signs my stuff, especially my own scripts and automation? Me of course, if I had good tooling.
If that became normal malware would just steal the key.
A TPM or other keybearer device lets you conditionally unlock a signing key.
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.
With good enough tooling this is workable.
If implemented well, this even helps maintenance of the system.
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.
+ 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.
There's already a mechanism, provided for DKMS - you enrol a 'Machine Owner Key' which only root can access, and any time you update your kernel (requiring you to recompile a kernel module), it gets signed with the MOK. Which of course means any malware that gains root access can sign itself too.
An alternative is that any time you update your kernel and reboot, things like the nvidia drivers would get disabled until you perform some special ceremony. Not that great for usability, we want people to install updates in a timely manner after all so we don't want to make it too inconvenient.
Another alternative is to only load code blessed by a Microsoft-approved Linux distro - the Ubuntu Core approach. But this requires abandoning the open source ethos.
> 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.
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.
4. GRUB itself has a password defined, with similar password strength requirements.
5. Editing the kernel command line or accessing the raw GRUB command prompt requires the password and, likewise, cannot be used to boot kernel/initrd pairs from external media.