InitWare, a portable systemd fork running on BSDs and Linux

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

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.

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.

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.

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?

[0] - https://github.com/Foxboron/sbctl

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.

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).

"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.

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?

> signed shim

How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.

You don't but 99.99% of people do :) Especially because most Linux distros use a key signed by Microsoft by default.

> 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.

> but I don't know how to implement it so it can't be used to lock you out of your own computer.

You probably need Heads with Librem Key, like Purism offers for their laptops.

Because manufacturers aren't trying to add surreptitious implants. They're trying to prevent you installing operating systems other than the one they get a bulk discount if they force you to have.

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.

[0] : https://news.ycombinator.com/item?id=42884727

Whatever the intent, the point stands: why would they need secure boot to do that? They could just do it with proprietary controls. So how does the existence of secure boot as a user-controlled feature affect that risk?

The “people” don’t really matter.

Anyone who needs a secure boot environment is having their own MOK and probably a private CA.

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.

The specific proprietary controls you're referring to are called "secure boot".

I think that is a uselessly reductive interpretation of what secure boot is because you could apply the same logic to any security technology. Why should we allow login passwords or user permissions or disk encryption, since those could be used as lock-out technologies by manufacturers, if they just ship them with defaults you can't control?

Manufacturers don't need any user-facing standardized controls to implement lockouts. So the possibility of a feature being used as a lockout shouldn't be a justification for taking away the option of having a user-controlled security feature. Taking it away from users isn't going to stop manufacturers from doing it anyway with proprietary technologies instead.

They aren't doing that either. It's a tiresome point of FUD that comes up in every thread on secure boot.

Because manufacturers do use secure boot to prevent you changing your OS and don't use fingerprint recognition to prevent you selling your device to someone else. If they did the latter, that would also be bad, but they don't.

An adversary can usually only modify code that executes in the boot process if they already have root privileges, or if they have physical access. In either of those cases the game is already over anyway.

> or if they have physical access.

If you're not worried about physical access, then why would you encrypt your disk at all?

Encrypted disks saves you from an unsophisticated attacker. Also, full disk encryption enables the feature of using a power plug switch as a ”lockdown mode” button.