Disabling Secure Boot signature validation

[mjg59]

One of the benefits of the Shim approach of bridging trust between the Microsoft key and our own keys is that we can define whatever trust policy we want. Some of the feedback we've received has indicated that people really do want the ability to disable signature validation without having to go through the firmware. The problem is in ensuring that this can't be done either accidentally or via trivial social engineering.

We've come up with one possible solution for this. A tool run at the OS level generates a random password and hashes it. This hash is appended to the desired secure boot state and stored in an EFI variable. On reboot, Shim notices that this variable is set and drops to a menu. The user then selects "Change signature enforcement" and types the same password again. The system is then rebooted and Shim now skips the signature validation.

This approach avoids automated attacks - if malware sets this variable, the user will have no idea which password is required. Any social engineering attack would involve a roughly equivalent number of steps to disabling Secure Boot in the firmware UI, so it's not really any more attractive than just doing that. We're fairly confident that this meets everyone's expectations of security, but also guarantees that people who want to run arbitrary kernels and bootloaders can do so.

Comments

Re: How do they know the password

[mjg59]

On reboot you'll be faced with a prompt saying "Continue" and a countdown. If you select "Continue" or wait for the timer to expire, your system will boot. You'll need to select "Disable Secure Boot" and then type the password.

Could malware convince users to do that? Yes. Could malware convince users to just do the same through their firmware menus? Yes. If the option exists (as Microsoft require it to on x86) there will always be some people who can be convinced to change it without knowing what they're doing. There's no way of keeping those people safe.

Re: How do they know the password

[(Anonymous)]

Enforcing a minimum password length (or even a complexity, e.g. requiring a digit) within a shim would make this kind of attacks more difficult.

At the very least, a zero-length password should definitely be prohibited.

Re: How do they know the password

[mjg59]

Yeah, right now the password has to be 8 characters. We could definitely enforce some additional constraints there.

Re: How do they know the password

[(Anonymous)]

One way to enforce ugliness of passwords would be to require that the password be a hash of some information provided to the firmware by the userland program, so the userland program can only choose a password if it can reverse the hash. OTOH, that might require rather long passwords and does rather conflict with sending the password to the firmware as a hash.