Further UEFI bootloader work
Oct. 11th, 2012 10:45 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I've been continuing to work on Shim this week, and it's now getting pretty close to feature complete. The biggest change has been migrating the MokList variable from a custom format to the one used by the UEFI spec databases, which means it's easier for the kernel to import the MOK entries and use them for validating module signatures.
The other benefit of this format is that it supports hashes as well as certificates, and so I've added support for enrolling hashes through the MokManager UI. This means that distributions can now ship with a signed copy of Shim without having to sign any other components of their distribution. When the user attempts to boot off the media they'll be faced with a menu and a countdown. If the countdown reaches 0, the system will simply fall back to the next entry in the bootlist. If they hit a key, they can choose to enrol a hash. The user then navigates the filesystem explorer, chooses the bootloader, confirms that they want to enrol it and then exits. Shim then verifies the bootloader against the hash and boots successfully.
The big advantage of this over the Linux Foundation approach is that once a hash has been enrolled the need for physical end-user presence is removed - ie, if you enrol the hash, you don't need to hit a key every time you boot. This is still slightly sub-optimal in that if you update your bootloader you'll need to enrol a new hash, but that can be partially automated by calling MokUtil in the postinst - the user then simply needs to confirm that they want to enrol the hash, rather than having to choose it manually. Completely transparent updates are going to require a signed bootloader and an enrolled signing key.
A couple of people have asked whether we're planning on implementing the Linux Foundation approach of simply asking the user whether they want to boot an unsigned file. We've considered it, but at the moment are leaning towards "no" - it's simply too easy to use to trick naive users into running untrusted code. Users are trained to click through pretty much any security prompt that they see, and if an attacker replaces a legitimate bootloader with one that asks them to press "y" to make their computer work, they'll press "y". If that bootloader then launches a trojaned Windows bootloader that launches a trojaned Windows kernel, that's kind of a problem. This could be somewhat mitigated by limiting this feature to removable media, and we're seriously considering that, but there are still some risks associated. We might just end up writing the code but disabling it at build time, and then anyone who wants to distribute with that policy can do so at their own risk.
Meanwhile, Peter Jones is working on tidying up the code we're using for the actual signing and will be publishing that once the last couple of kinks are worked out. We're using hardware cryptography, so even if someone compromises the build systems they won't be able to obtain the private key that we use. However, should something disastrous and unanticipated happen, we do have a plan in place for migrating to new keys with minimal user impact. We'll document the code and infrastructure we're using in order to make it as easy as possible for other distributions to implement equivalent functionality.
As I've mentioned before, our goal is to make it as easy as possible for distributions to implement whatever level of Secure Boot policy they want without having to engage with Microsoft themselves. Shim allows distributions to ship an OS that has no signed binaries at all, or alternatively to ship an OS that uses filesystem-level cryptography to ensure that even userspace is completely signed. I'm expecting to see a range of options available, and I hope that the majority of users will find something to suit their needs.
The other benefit of this format is that it supports hashes as well as certificates, and so I've added support for enrolling hashes through the MokManager UI. This means that distributions can now ship with a signed copy of Shim without having to sign any other components of their distribution. When the user attempts to boot off the media they'll be faced with a menu and a countdown. If the countdown reaches 0, the system will simply fall back to the next entry in the bootlist. If they hit a key, they can choose to enrol a hash. The user then navigates the filesystem explorer, chooses the bootloader, confirms that they want to enrol it and then exits. Shim then verifies the bootloader against the hash and boots successfully.
The big advantage of this over the Linux Foundation approach is that once a hash has been enrolled the need for physical end-user presence is removed - ie, if you enrol the hash, you don't need to hit a key every time you boot. This is still slightly sub-optimal in that if you update your bootloader you'll need to enrol a new hash, but that can be partially automated by calling MokUtil in the postinst - the user then simply needs to confirm that they want to enrol the hash, rather than having to choose it manually. Completely transparent updates are going to require a signed bootloader and an enrolled signing key.
A couple of people have asked whether we're planning on implementing the Linux Foundation approach of simply asking the user whether they want to boot an unsigned file. We've considered it, but at the moment are leaning towards "no" - it's simply too easy to use to trick naive users into running untrusted code. Users are trained to click through pretty much any security prompt that they see, and if an attacker replaces a legitimate bootloader with one that asks them to press "y" to make their computer work, they'll press "y". If that bootloader then launches a trojaned Windows bootloader that launches a trojaned Windows kernel, that's kind of a problem. This could be somewhat mitigated by limiting this feature to removable media, and we're seriously considering that, but there are still some risks associated. We might just end up writing the code but disabling it at build time, and then anyone who wants to distribute with that policy can do so at their own risk.
Meanwhile, Peter Jones is working on tidying up the code we're using for the actual signing and will be publishing that once the last couple of kinks are worked out. We're using hardware cryptography, so even if someone compromises the build systems they won't be able to obtain the private key that we use. However, should something disastrous and unanticipated happen, we do have a plan in place for migrating to new keys with minimal user impact. We'll document the code and infrastructure we're using in order to make it as easy as possible for other distributions to implement equivalent functionality.
As I've mentioned before, our goal is to make it as easy as possible for distributions to implement whatever level of Secure Boot policy they want without having to engage with Microsoft themselves. Shim allows distributions to ship an OS that has no signed binaries at all, or alternatively to ship an OS that uses filesystem-level cryptography to ensure that even userspace is completely signed. I'm expecting to see a range of options available, and I hope that the majority of users will find something to suit their needs.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-12 05:09 am (UTC)> "When the user attempts to boot off the media they'll be faced with a menu and a countdown. If the countdown reaches 0, the system will simply fall back to the next entry in the bootlist. If they hit a key, they can choose to enrol a hash. The user then navigates the filesystem explorer, chooses the bootloader, confirms that they want to enrol it and then exits."
And then:
> "This is still slightly sub-optimal in that if you update your bootloader you'll need to enrol a new hash, but that can be partially automated by calling MokUtil in the postinst - the user then simply needs to confirm that they want to enrol the hash, rather than having to choose it manually. Completely transparent updates are going to require a signed bootloader and an enrolled signing key."
I'm a bit confused by these two paragraphs.
Does it mean that if Fedora pushes a grub2 update, the user will have to enroll the new hash? Or will Fedora sign the updated grub2 in a way that makes the update completely transparent?
I really hope I won't have to guide my parents through enrolling a hash over the phone (the alternative being that they don't use their computer until the next time I go back to France for Christmas). :-/
no subject
Date: 2012-10-12 05:15 am (UTC)It's a little more difficult with small distributions. If they do their own signing and supply their own key, but are shipping a version of shim that doesn't trust that key, you'll need to enrol that key as a one-off event. If they don't do any signing you'll need to enrol the hash of the bootloader every time the bootloader changes.
Hazards of user interaction
Date: 2012-10-12 05:17 am (UTC)Since distros can easily sign their bootloader themselves with a key they control, why not require distros to do so, to ensure that users do not become accustomed to seeing bootloader enrollment prompts at boot time other than the very first boot after installing a distro? Then, if a user sees an enrollment prompt at any other time, they will regard it with much more suspicion.
Especially if, as a one-time prompt, it explicitly makes you type out "I just installed Linux" or something similarly designed to cause a "stop and think" reaction.
Re: Hazards of user interaction
Date: 2012-10-12 05:23 am (UTC)Re: Hazards of user interaction
Date: 2012-10-12 06:35 am (UTC)Re: Hazards of user interaction
Date: 2012-10-12 06:39 am (UTC)Re: Hazards of user interaction
Date: 2012-10-12 09:51 am (UTC)Re: Hazards of user interaction
Date: 2012-10-12 01:49 pm (UTC)Re: Hazards of user interaction
Date: 2012-10-12 03:39 pm (UTC)(Hint: it probably doesn't.)
Re: Hazards of user interaction
Date: 2012-10-12 03:42 pm (UTC)Re: Hazards of user interaction
Date: 2012-10-12 11:13 pm (UTC)Re: Hazards of user interaction
Date: 2012-10-12 11:21 pm (UTC)no subject
Date: 2012-10-12 02:32 pm (UTC)If you boot an unsigned image, will you have an message if you want to load an unsigned image?
And can this shim boot a non-Linux operating system?
no subject
Date: 2012-10-12 02:43 pm (UTC)no subject
Date: 2012-10-12 05:45 pm (UTC)no subject
Date: 2012-10-12 05:58 pm (UTC)What about storage driver updates at install time?
Date: 2012-10-16 04:07 pm (UTC)Let's say there's some new storage hardware and a distro can't install to it without an updated driver. What does the vendor of that hardware have to do to make sure they can get their updated driver to be loaded by the distro's kernel at installation time? Or maybe the "at installation time" is not important, as I suppose whatever keys or signing or whatever that needs to be done would be the same after install time as well?
Thanks,
-- steve
Re: What about storage driver updates at install time?
Date: 2012-10-16 04:22 pm (UTC)Re: What about storage driver updates at install time?
Date: 2012-10-16 05:07 pm (UTC)-- steve
Re: What about storage driver updates at install time?
Date: 2012-10-16 05:13 pm (UTC)Re: What about storage driver updates at install time?
Date: 2012-10-16 05:17 pm (UTC)-- steve
no subject
Date: 2012-10-17 06:14 pm (UTC)Will the shim get installed if I have secure boot disabled before I install Linux?
And why do you want to sign the kernel if you said earlier that signing the kernel will complicate custom kernels and DKMS? Why don't you just sign the bootloader, call ExitBootServices, and then call the kernel and forget about signing the kernel?
no subject
Date: 2012-10-17 06:16 pm (UTC)