Comment by udev4096
Comment by udev4096 9 days ago
systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html
Comment by udev4096 9 days ago
systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html
"on a system not configured for boot security, you get no boot security" is indeed correct. If you care about boot security, your local platform doesn't give you the chance to boot custom kernels and not passing secure boot doesn't give you decryption keys.
There are multiple possible configurations. Only the most basic will permit an arbitrary payload as you describe.
I've never been entirely clear about the security model when the signed shim is permitted. I assume I'm missing some nuance.
Disk encryption alone won't protect you from either persistent malware (remote) or evil maids (local).
> The only boot security real users need is disk encryption.
Which becomes easy to bypass without boot security. If an adversary can modify code that executes in the boot process, they can steal your keys.
> or if they have physical access.
If you're not worried about physical access, then why would you encrypt your disk at all?
> signed shim
How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.
The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo.
I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.
The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation.
The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though.
In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.
If the manufacturer wanted to conduct a supply chain attack on you, they wouldn't need secure boot to do it. They could just design an implant of their own using proprietary technology.
So why does the presence of secure boot as a user-controlled feature affect that risk calculation?
They aren't doing that either. It's a tiresome point of FUD that comes up in every thread on secure boot.
sbctl [0] makes secure boot a lot easier. you just enable setup mode from BIOS and it will take care of enrolling and managing the keys. Are you immibis from libera.chat by any chance?
There was this SixOS presentation[0] 2 months ago of a single man's own distro, among a lot of things he claims that he's created the most secure boot process ever
> On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm.
Most 'systemd haters' see boot security as unnecessary, or a toy no one would use, and that UEFI secure boot is a conspiracy orchestrated by Microsoft.
It fits the personality profile of not wanting to learn new things. After all, we didn't need it in 2002, so why do we need it now?
There is no fixing these people, so it doesn't make sense expending energy convincing them.
That's almost entirely correct, with one exception:
> It fits the personality profile of not wanting to learn new things.
'systemd haters' learn a lot. They learn how to write manual boot scripts, set up mdev instead of udev, compile their own kernel, install their own u-boot or coreboot, strip binary blobs, etc. etc. They know MORE than the average systemd guy. They just don't want to learn systemd.
Isn't the whole purpose of systemd to ease and automate administration and configuration, so the user need not care? Doesn't that imply that systemd admins/users know LESS?
----
Now let me make my own characterization of 'systemd enthusiasts'.
These people are overworked sysadmins that hate manual configuration. They want it easy, everything automated, they want to not care about it, they want the distro to auto-do everything and not even ask, they want less admin work. Systemd does all these things for them and they are in heaven. They're so enthusiastic that they feel we should all be one big happy family under the systemd umbrella.
But they fail too see that no company or manager will tolerate people that are _not_ overworked.
When something becomes automated, people previously doing the manual job are fired. A 10 people non-systemd team that works day-and-night to set manually up boot, mounts, network, services, cron, backups, logs, etc., as soon as systemd automates the work, will be cut down to just one guy (or less) and he will still work day-and-night, same as before, doing the work of the entire team. And he won't be able to take break because there's nobody left to replace him.
They also fail to see that resilience comes from diversity. Uniformity, systems where software is identical, updates are identical, configuration is identical, permissions are identical, etc., will also fail identically and probably at the same time, and will be hacked identically and at the same time (by automated bots/tools).
An enjoyable perspective on how workload can affect techno-tribalism. Like many who have worked in, or run, mixed shops over the years, I've lamented the interpersonal friction that can happen amongst camps. It can be corrosive, almost to the point of destruction, at which point I've had to fire people for using terms like ''hater'' or worse. Good riddance, because we had work to do.
As someone who uses systemd, "boot security" is pointless. If someone has enough access to your hardware to try booting a different kernel, they have time to load a signed shim that passes secure boot and launches unsigned code.
The only boot security real users need is disk encryption.