I'm not against this system in general, but this is literally the "we told you so" situation that anti-secureboot folks objected to.
Conversation
Basically any security technology can be abused to restrict user freedom - that means we need to push back against such abuses, not that we should necessarily reject the technologies in the first place
1
51
Needing to manually enable trusting third party boot chains is a minor inconvenience at most and not a restriction on what you can do. Their ecosystem has almost entirely theatrical implementations of secure boot and attestation. Many things would have to be fixed, this is one.
1
3
Proper approach would be only trusting first party boot chain by default, having a very easy way for users to add public key of other operating systems and filling in all the stuff that's missing like downgrade protection for secure boot itself. Attestation doesn't replace it.
1
3
It's an incomplete implementation of secure boot where there are multiple things missing for both firmware and the OS. One of the things they would need to do to turn it into a serious implementation is exactly this. Shim bootloader has no place in a serious implementation of it.
2
2
With the latest kernel release you *need* a shim if you want to enable lockdown mode and sign kernel modules.
There is simply no other way for you as a user to enroll a set of trusted keys in the kernel keyring at the moment.
I find this absurd.
2
1
In order for verified boot to actually work properly, it has to cover far more of the OS than the kernel. Lockdown mode isn't enough to actually provide users with any real security properties. It's overly inflexible too since it's entirely based on an insecure/useless approach.
1
One of the most basic properties you can provide with secure boot is a way for the user to trigger a special UI on boot for wiping everything not covered by secure boot. That requires getting to the point you verify an initramfs so that you can actually do something meaningful.
1
Presumably also requires having the entire base OS verified or at least having a way for the initramfs to wipe everything and re-create it from a verified image.
If you want to do anything more than providing reliable reset to a known state, that requires a whole lot more work.
1
Since you have to verify the entire base OS and then avoid trusting anything outside it without having a way to chain trust to it. If you have a way for something to persist root access / equivalent that's a bypass. Anything persistent state is trusted to do isn't covered by it.
1
If a security feature can be disabled through persistent state outside of what's verified, that feature hasn't been implemented for the secure boot threat model. Only what you can provide to the user with verified portion of the OS with all persistent state malicious is covered.