So there you have it: recommending idly Secure Boot for all systems requiring intermediate security level accomplishes nothing, except maybe giving more work to system administrators that are recompiling their kernel, while offering exactly no measurable security against many threats if UEFI Administrative password and MOK Manager passwords are not set. This is especially true for laptop systems where physical access cannot be prevented for obvious reasons. For servers in colocation, the risk of physical access is not null. And finally for many servers, the risk of a rogue employee somewhere in the supply chain, or the maintenance chain cannot be easily ruled out.
The author makes a compelling case, but my knowledge on this topic is too limited to confidently present this article as a good one. I’ll leave it to those among us with more experience on this subject to shoot holes in the article, or to affirm it.
I wouldn’t have minded secure boot as much if owners had been fairly represented in it’s development. All the design decisions in secure boot seemed to point to a desire to control owners rather than empower us. After public outcry MS gave owners the explicit right to disable secure boot on their own x86 machines. Still the standard leaves a lot to be desired. It provides vendors with standard secure mechanisms to install their keys, but there are no provisions in the standard for owners to do this at all! And I think it speaks to the intent of designers that the standard itself disregarded the notion of owner control completely. Thankfully some BIOS vendors gave us this control anyways. Most of us are extremely fortunate that forced secure boot didn’t pan out and I hope it never does. I’m all for real security, but not when “security” is a euphemism for a walled garden.