Comment by exceptione
7 days ago
The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.
I think Systemd has a view that those things should reliably work together. I do not fancy a revival of the past where the user has to cobble a mesh of hopefully compatible libraries to achieve the same, taking weeks to study the Arch manual and resolving tons of gotcha's, all to be broken by next week's update.
The integration of all this stuff is now actively under test and maintenance with systemd.
And yes, the mentioned services also have an impact on the scope of service managing. Because if you have a unit that depends on a disk that needs to be unencrypted, this has to be resolved somehow in the right time.
I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large.
So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?
> The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.
These are also all components which would be extremely difficult to make portable - they require tight integration with the kernel and its boot process. I can't imagine how you'd implement them in a portable fashion, short of either making changes to the kernel on one or both operating systems, or implementing a complex set of shims to make them present similar interfaces. Either one of those options would be a sizable project on its own - I can't fault the developer from shying away.
Good point. But it seems that it leaves you a choice of something that is either portable or feature-rich.
It all depends on the purpose of the fork. If it is there to just provide the common service layer for applications in order to make applications portable, I could see a fork being valuable.
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
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.
"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.
3 replies →
> signed shim
How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.
2 replies →
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.
> 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.
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?
6 replies →
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
1 reply →
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).
1 reply →
> The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.
This has not been my experience across Debian and Arch
That's because Debian 'stable' has a half-assed implementation of systemd, frozen in time on some ancient version. So you are stuck waiting years between upgrades. Bookworm finally supports the crypto functions.
Arch OTOH was where these functions first worked out of the box.
> frozen in time on some ancient version.
Yeah that's a feature of Debian stable
4 replies →
Arch user here. These things work much nicer than any of the previous alternatives. Sure, kernel signing is a bit of a mess, but that's more of a product of how key-signing at a low-level works than anything. Cryptsetup, cryptenroll, unified kernel images, and systemd-boot worked for me out of box.
They very much did not for me. I beat things into shape with sbctl but it was very much an uphill battle.
idk why Arch seems allergic to packaging shim-signed (it's an AUR, why would I trust such a key component to essentialy a stranger?), but here we are I guess.
2 replies →
Am on Arch and I use them with unattended boot(TPM) and they work flawlessly.
My cryptenroll is currently broken by the latest system update (I think it was a bios update). It’s better, but I’m not sure it’s good.
somehow they missed journal though...