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.
Conversation
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
This isn't true? Just enroll a signing key into db and also the kernel.
1
1
It is, actually. The db keys being loaded into the trusted keyring is from a rejected upstream patch.
The one that has been accepted is from Snowberg and enrolls keys from the MokList into the platform keyring. These variables are setup in the mok EFI configuration table.
2
Yes, so you just build then into the kernel directly
1
This complicates distro packaging. This is also not what distros that support secure boot is currently doing, as they have users resign dkms modules locally.
My gripe is mainly that there is no way to have a trusted key after the kernel is built, unless you use the shim.
2
1
If users have the private signing keys locally, there isn't really any meaningful secure boot for the kernel. You can't really use DKMS for the kernel. In my opinion the entire thing is a moot point because desktop distributions aren't verifying beyond the kernel at this point.
1
i.e. they aren't even providing a way to boot a recovery interface for restoring the OS to a known good state based on verified recovery images, let alone verifying everything during a normal boot.
The problem with lockdown is it basically assumes you aren't doing any of that.
1
Android doesn't use signed kernel modules but rather verifies entire base OS and only allows loading kernel modules from the verified base OS. If you want to distribute out-of-band kernel module updates, you distribute them in an APEX which is an APK with a verified fs inside.
The initramfs which is used as the root fs even after early boot is verified and loads the security policies. Lockdown is essentially all or nothing even though you can easily enforce a lot of those things through your verified userspace to enable more real world use cases.
1
Even with the whole base OS verified, providing real security properties to users is hard. In the main threat model (remote compromise in previous boot), attacker controls all the persistent state, so you can assume they have all permissions, special access grants, etc.
1
Show replies