![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I'm pleased to say that a usable version of shim is now available for download. As I discussed here, this is intended for distributions that want to support secure boot but don't want to deal with Microsoft. To use it, rename shim.efi to bootx64.efi and put it in /EFI/BOOT on your UEFI install media. Drop MokManager.efi in there as well. Finally, make sure your bootloader binary is called grubx64.efi and put it in the same directory.
Now generate a certificate and put the public half as a binary DER file somewhere on your install media. On boot, the end-user will be prompted with a 10-second countdown and a menu. Choose "Enroll key from disk" and then browse the filesystem to select the key and follow the enrolment prompts. Any bootloader signed with that key will then be trusted by shim, so you probably want to make sure that your grubx64.efi image is signed with it.
If you want, you're then free to impose any level of additional signing restrictions - it's entirely possible to use this signing as the basis of a complete chain of trust, including kernel lockdowns and signed module loading. However, since the end-user has explicitly indicated that they trust your code, you're under no obligation to do so. You should make it clear to your users what level of trust they'll be able to place in their system after installing your key, if only to allow them to make an informed decision about whether they want to or not.
This binary does not contain any built-in distribution certificates. It does contain a certificate that was generated at build time and used to sign MokManager - you'll need to accept my assurance that the private key was deleted immediately after the build was completed. Other than that, it will only trust any keys that are either present in the system db or installed by the end user.
A couple of final notes: As of 17:00 EST today, I am officially (rather than merely effectively) no longer employed by Red Hat, and this binary is being provided by me rather than them, so don't ask them questions about it. Special thanks to everyone at Suse who came up with the MOK concept and did most of the implementation work - without them, this would have been impossible. Thanks also to Peter Jones for his work on debugging and writing a signing tool, and everyone else at Red Hat who contributed valuable review feedback.
Now generate a certificate and put the public half as a binary DER file somewhere on your install media. On boot, the end-user will be prompted with a 10-second countdown and a menu. Choose "Enroll key from disk" and then browse the filesystem to select the key and follow the enrolment prompts. Any bootloader signed with that key will then be trusted by shim, so you probably want to make sure that your grubx64.efi image is signed with it.
If you want, you're then free to impose any level of additional signing restrictions - it's entirely possible to use this signing as the basis of a complete chain of trust, including kernel lockdowns and signed module loading. However, since the end-user has explicitly indicated that they trust your code, you're under no obligation to do so. You should make it clear to your users what level of trust they'll be able to place in their system after installing your key, if only to allow them to make an informed decision about whether they want to or not.
This binary does not contain any built-in distribution certificates. It does contain a certificate that was generated at build time and used to sign MokManager - you'll need to accept my assurance that the private key was deleted immediately after the build was completed. Other than that, it will only trust any keys that are either present in the system db or installed by the end user.
A couple of final notes: As of 17:00 EST today, I am officially (rather than merely effectively) no longer employed by Red Hat, and this binary is being provided by me rather than them, so don't ask them questions about it. Special thanks to everyone at Suse who came up with the MOK concept and did most of the implementation work - without them, this would have been impossible. Thanks also to Peter Jones for his work on debugging and writing a signing tool, and everyone else at Red Hat who contributed valuable review feedback.
Microsoft signed? Is that "secure"?
Date: 2012-12-01 02:16 pm (UTC)Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 02:54 pm (UTC)This "security" is fake. It's "restricted" boot, not "secure".
Date: 2012-12-01 03:32 pm (UTC)P.S. still this bootloader is an incredible workaround to these crappy initiatives where you're FORCED to "trust" to entities you have no reason to trust at all. However as for me at this point I would consider whole x86 platform with UEFI to be untrusted due to all this activity. If someone forces you to "trust" by pointing you with their gun and leaving no other options, you know, this "trust" is a big fake.
P.s.: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." - B. Franklin.
Re: This "security" is fake. It's "restricted" boot, not "secure".
Date: 2012-12-01 04:12 pm (UTC)P.S. To MG - I like your (not)captcha technique. Yours, or did you get it elsewhere? :-)
-Rubberman
Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 08:06 pm (UTC)Does this mean that one day in the future this shim loader could be (accidentally/deliberately) blacklisted, bricking all the devices that rely on it ?
Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 08:08 pm (UTC)Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 08:20 pm (UTC)Re: Microsoft signed? Is that "secure"?
Date: 2012-12-02 03:22 am (UTC)If they come from Windows Updates and you're not running Windows at all, then it seems unlikely that your system would suddenly stop working.
Of course, this assumes that the firmware doesn't have some way to update the revocation lists on its own.
Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 03:00 pm (UTC)Naer a week passes when we don't hear of new malware breaching Windows defences; which seems to have escaped the attention of those who would spruik this (secure boot) dreadful imposition.
The greatest threat appears to lie in Windows itself, either application or system code. Guarantees that windows loads without interference seems to me to be a hollow victory.
Newall
Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 09:02 pm (UTC)It has nothing to do with security despite being marketed as such
Re: Microsoft signed? Is that "secure"?
Date: 2012-12-01 09:04 pm (UTC)