> Adding such an ability removes the security right?
No, because the mechanism used for this requires proof that you have access to the console - a remote attacker can't do it. A local attacker could, but there's support for passwording it to prevent this (it's equivalent to passwording the firmware setup)
> I acknowledge I may be misunderstanding this
You are, but there's a huge amount of misinformation about this stuff out there that makes it hard to find the actual information, so it's not surprising :)
I forsee this as a step in many online guides on "how do I [x] on linux"
Edit:
Having thought about this some more, I think perhaps we can model this workaround after SELinux. Sure, there were trivial cases (my wine game mmaps 0x0 and now doesn't work, after wunderbar emporium), but more often it was something like "My apache can't read my directory" "Just run setenforce 0 and try again" which then, rather than being followed up with audit2allow, usually results in the search "How to disable SELinux permanently".
The fundamental problem is that, and you've covered this ground plenty of times, Secure boot is not secure by default. We're not really affording much more security for the most vulnerable systems which is run by small time system administrators rather than large tech corporates.
Sure it would be great if we could educate people to protect their chain of trust (and arguably the best solution), but instead what we have is something which hampers usability, and opens the door to people who plan to come around and barricade the door after you.
So by tying in this security by default measure, we could arguably afford and even greater illusion of protection, which runs counter to the intent of extending the protection of secure boot. Anyone willing enough to protect their chain of trust explicitly is also going to be able to research the issue.
The flip side is that SELinux was adopted anyway. If there aren't actually that many server use cases which require this work around, then: Protection, awesome. But unlike SELinux policy, Lockdown policy is baked into the kernel (right?). If there are any issues, there is only one solution: disable Kernel Lockdown, which might be achieved by disabling secure boot validation.
Run sudo mokutil --disable-validation
> Adding such an ability removes the security right?
No, because the mechanism used for this requires proof that you have access to the console - a remote attacker can't do it. A local attacker could, but there's support for passwording it to prevent this (it's equivalent to passwording the firmware setup)
> I acknowledge I may be misunderstanding this
You are, but there's a huge amount of misinformation about this stuff out there that makes it hard to find the actual information, so it's not surprising :)