[personal profile] mjg59
I'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.

Date: 2012-10-12 05:09 am (UTC)
From: [identity profile] bochecha.id.fedoraproject.org
You write:

> "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). :-/

Hazards of user interaction

Date: 2012-10-12 05:17 am (UTC)
From: (Anonymous)
If you can enroll a new hash at boot time, what means does the average user have of knowing that they're enrolling a legitimate bootloader? EFI Secure Boot supposedly exists to protect against firmware-based and bootloader-based attacks, right? What happens if some exploit replaces the bootloader when using shim? (Perhaps a Windows-based exploit targeting dual-boot users, or perhaps a Linux-based exploit.) A user will see a prompt to replace their bootloader, and as you've suggested, they'll just do so without thinking because they just want the prompt to go away. Compared to the case with a signed bootloader, it seems like you've reduced what little security EFI Secure Boot has.

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 06:35 am (UTC)
From: (Anonymous)
eg, Shim will *never* say "Your bootloader seems to have changed, would you like to run it anyway? (Y/N)" as the user will just hit Y without thinking.

Re: Hazards of user interaction

Date: 2012-10-12 09:51 am (UTC)
From: (Anonymous)
Let's assume, for the moment, that whatever wants to boot a malicious bootloader has used the same mechanism you suggested a Linux distribution could use to pre-select a bootloader. Then, the user need not navigate the filesystem. With the bootloader not signed, the user need not select what key to install. Given those assumptions, what does the workflow look like for the user to enroll the hash of a malicious bootloader, and how does it differ from what a user will see when they upgrade from one version of a non-malicious bootloader to another?

Re: Hazards of user interaction

Date: 2012-10-12 03:39 pm (UTC)
From: (Anonymous)
And that differs from the workflow after legitimately upgrading the bootloader how?

(Hint: it probably doesn't.)

Re: Hazards of user interaction

Date: 2012-10-12 11:13 pm (UTC)
From: (Anonymous)
I'm wondering why it makes sense to support unsigned bootloaders at all. Why not require a signature, always enroll a key rather than a hash, and complain bitterly when the key changes?

Date: 2012-10-12 02:32 pm (UTC)
From: (Anonymous)
I have two questions about your shim.
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?

Date: 2012-10-12 05:45 pm (UTC)
From: (Anonymous)
How close are we to a working, released Shim that is signed by Microsoft's key? Is it still in question whether or not Microsoft will be willing to sign the Shim?
From: (Anonymous)
Maybe you could elaborate a bit on how driver updates will work compared to how they work without secure boot.

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
From: (Anonymous)
Generally we do get our code upstream (hpsa, and cciss drivers for HP's Smart Array RAID controllers are what I'm thinking of specifically) but, storage product releases have a way of not lining up with distro releases, and customers like to run very old distros quite frequently, so, without a time machine, getting the code upstream in those cases is not possible.

-- steve
From: (Anonymous)
Thanks for taking the time to explain all this on your blog. Interesting stuff.

-- steve

Date: 2012-10-17 06:14 pm (UTC)
From: (Anonymous)
I have a few questions.
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?

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags