I’d add WSL2 to your list of interesting Microsoft moves. The fact it allows for docker to run natively on windows and VS Code to use Linux tools feels classic EEE.
For what it’s worth, Microsoft’s own requirements for SecureBoot say that the owner must be able to add his own root keys to the firmware’s truststore. If you wish, you can remove all Microsoft keys from firmware truststore and replace them with your own.
The problem is that now you need to manage that root certificate and keep it secure. That’s not trivial for individuals.
I’d love to see a good F/OSS solution to this that makes it easy for an org to not just blindly trust RedHat or Canonical (for example), but only the specifically blessed kernel and boot environment settings that they want.
Me too, but it is a multifaceted problem. Not only do you have to maintain your own root certificate, but you also need remote attestation to ensure that everyone is in fact running the blessed kernel and boot environment. And honestly, I think the remote attestation part is the harder one.
That’s less vital as a starting point. If you install the machines with full-disk encryption where the key is tied to the PCR that contains your org’s certificate then anyone who boots an unauthorized kernel will lose access to the disk. If your threat model is an employee who wants to run a custom Linux distro that doesn’t meet your security policy, that’s a problem. If your threat model is someone stealing an employee’s laptop and using an old version of some signed Linux kernel with a known vulnerability to boot, unlock the disk, and then break into and steal your org’s data, then it’s fine. The second use case is the one that I care more about.
I have not seen a case where you actually can’t. It might be hard to find, with no standardized naming whatsoever, and possibly breaking some drivers built into devices, but from what I’ve experienced, the ability is always there.
And yet there’s hardware made by Microsoft themselves that doesn’t comply with this requirement. For example, as far as I can tell, the Surface Pro 8 allows you to disable secure boot, but doesn’t let you add your own keys - you can only use Microsoft’s keys or disable Secure Boot entirely.
AFAICT, you can use your own keys, but you still need to use ones from Microsoft too (ref). Which makes some sense, since SecureBoot is also used for device drivers, for which on a Surface Pro 8 Microsoft is responsible.
You can disable secure boot entirely, or use Microsoft’s keys. A proper implementation of Secure Boot should allow you to enter secure boot Setup mode and enroll your own PK and KEKs.
Secure boot isn’t used for device drivers unless you mean UEFI option ROMs. I’m not sure UEFI option ROMs are relevant as this is an Intel platform with integrated graphics and I doubt any option ROMs are needed. (Even if they were, that doesn’t mean you should be forced to trust the key which signs them; UEFI can also whitelist hashes of specific binaries IIRC, so that’s always an option.)
the future needs to start with this coming to an end:
Microsoft:
Perhaps this is all coincidence, but it’s starting to feel like a plan is coming together. Very A-Team, only with Nadella chewing on the cigar.
I’d add WSL2 to your list of interesting Microsoft moves. The fact it allows for docker to run natively on windows and VS Code to use Linux tools feels classic EEE.
EME stands for “Encrypted Media Extensions” for those who don’t know
For what it’s worth, Microsoft’s own requirements for SecureBoot say that the owner must be able to add his own root keys to the firmware’s truststore. If you wish, you can remove all Microsoft keys from firmware truststore and replace them with your own.
The problem is that now you need to manage that root certificate and keep it secure. That’s not trivial for individuals.
I’d love to see a good F/OSS solution to this that makes it easy for an org to not just blindly trust RedHat or Canonical (for example), but only the specifically blessed kernel and boot environment settings that they want.
Me too, but it is a multifaceted problem. Not only do you have to maintain your own root certificate, but you also need remote attestation to ensure that everyone is in fact running the blessed kernel and boot environment. And honestly, I think the remote attestation part is the harder one.
That’s less vital as a starting point. If you install the machines with full-disk encryption where the key is tied to the PCR that contains your org’s certificate then anyone who boots an unauthorized kernel will lose access to the disk. If your threat model is an employee who wants to run a custom Linux distro that doesn’t meet your security policy, that’s a problem. If your threat model is someone stealing an employee’s laptop and using an old version of some signed Linux kernel with a known vulnerability to boot, unlock the disk, and then break into and steal your org’s data, then it’s fine. The second use case is the one that I care more about.
Implementations sometimes have trouble with allowing users to define their own trust store.
I have not seen a case where you actually can’t. It might be hard to find, with no standardized naming whatsoever, and possibly breaking some drivers built into devices, but from what I’ve experienced, the ability is always there.
And yet there’s hardware made by Microsoft themselves that doesn’t comply with this requirement. For example, as far as I can tell, the Surface Pro 8 allows you to disable secure boot, but doesn’t let you add your own keys - you can only use Microsoft’s keys or disable Secure Boot entirely.
AFAICT, you can use your own keys, but you still need to use ones from Microsoft too (ref). Which makes some sense, since SecureBoot is also used for device drivers, for which on a Surface Pro 8 Microsoft is responsible.
I’ve read that page and I don’t see how it says you can use your own keys. See the dialog: https://learn.microsoft.com/en-us/surface/images/manage-surface-uefi-fig3.png
You can disable secure boot entirely, or use Microsoft’s keys. A proper implementation of Secure Boot should allow you to enter secure boot Setup mode and enroll your own PK and KEKs.
Secure boot isn’t used for device drivers unless you mean UEFI option ROMs. I’m not sure UEFI option ROMs are relevant as this is an Intel platform with integrated graphics and I doubt any option ROMs are needed. (Even if they were, that doesn’t mean you should be forced to trust the key which signs them; UEFI can also whitelist hashes of specific binaries IIRC, so that’s always an option.)