Now, this only really makes sense if you are in some sort of trusted untampered environment already: if not, someone with root can stomp a new kernel in /boot/ which gives them a backdoor. So, lockdown without a trusted boot environment is security theater, since you can just take the long road anyway.
Additionally, in a trusted boot environment, the lockdown flag is wanted. If not, "trusted boot" really isn't such: someone that booted through a signed kernel can simply tamper with the kernel anyway after booting up through an init hook. The dangerous part: once they have the ability to tamper with the kernel, they can chainload another operating system and functional as a poisonous bootloader. The danger here is that if an attack like this is seen in the wild, and the attacker used, say, Fedora's kernel signing keys to do the attack, it has the possibility to get Fedora's keys blacklisted by OEMs. Linux would do best not to be used by an attacker as a "malware bootloader".
That means it's reasonable for, by default, lockdown to be informed by the presence of a trusted boot environment.
And just like that it stops being a magically enabled thing and becomes something you have to either have fully on or fully off.
If you want to protect against accidents then you can do that in userspace. There's no need for the kernel to be involved.
These protections should vastly reduce the risks of someone gaining root and make it much harder to do so to a running system with physical access. Or?
Seems to me that it is just as much security theater to pretend that it isn't game over if someone already has root.
edit: and perhaps the (by far?) biggest benefit of lockdown is to make it harder for someone to gain root?
a) locking root out of kernel
b) locking users from becoming root
I interpret the reasoning as: if we can't do a AND b we won't bother with b. Which is confusing because b is many orders of magnitudes more important than a.
In my opinion reducing that attack surface alone on b) has a much higher impact than a) could ever achieve.
A) Computers are tools designed to do whatever the user tells them to do.
B) The original architecture of the Internet assumed a network connecting implicitly trusted users
Stop trying to mess up a perfectly good tool by making it nigh impossible to work with, and redesign a networking/computing infrastructure that doesn't implicitly trust all users as a fundamental assumption.
This type of thing is getting completely out of hand.
If you want security SO badly you are willing to sacrifice billions of potential users freedoms to use their hardware as they see fit, coming up with a second "SECTERNET" architecture should be a price you're willing to pay right?
This pattern of trying to lock a user out of any tier of control of their own machine reeks of the continuing attempts by companies to deprive users of the privilege of ownership.
I realize it may be difficult to see for some, but this is a literal case of the road to Hell being paved with good intentions.
People don't need to be "protected" by building their volition out of the system.
Here's the bit I don't get: even if you can't be used as a chainloading malware bootloader, can't you still be used as a slightly more complicated malware bootloader that fires up the victim OS under virtualisation?
[0] https://en.wikipedia.org/wiki/Blue_Pill_(software) [1] http://northsecuritylabs.blogspot.com/2008/06/catching-blue-...
Exactly, and that's why lockdown and secure boot must be discarded. These are attempts to take control away from the user and give it to the OS maker or device manufacturer. This is exactly why I cannot root my android without losing hardware features and this is exactly why ios devices are not general purpose computers.
Fuck these anti-user efforts. They have no place in Linux.
Otherwise you could describe something like process memory protection the same way: not being able to read/write directly to a root process is taking the control away from the user after all.
What general purpose computation requires root?