So the concern is essentially that binary distributions, which are going to be responsible for kernel flags, may enable this, whether it is default in the default kernel config or not. As best as I can tell that is the crux of Linus' concerns. MJG suggesting that the kernel flag can be turned off, while true, is not a response which considers the defacto usage which may result.
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?
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?
Therefore the only real protection comes when you put your own keys in. In which case, once again, enable lock down in the kernel config. I imagine that is exactly something enterprise vendors would be looking at.
In the process of writing this, I have come to the conclusion that consumer secure boot is meaningless while the shim exists. The Microsoft approval process is, as I believe you said many years ago, fairly simple anyway. A company telephone number and a fee, if we're looking at other serious malicious actors.
I acknowledge I may be misunderstanding this, and that you've already been over most/all of these issues before. I don't mind if you feel a response is not necessary.
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 :)
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.
'This discussion is over until you give an actual honest-to-goodness reason for why you tied the two features together. No more "Why not?" crap.'
Notice LKML is from the 3rd of April, and MJGs blog post from the 4th of April.
Edit: correct initials
Somewhat annoyingly this puts me in a quandary, remove the incorrect top level post, thus the history in which the error was highlighted.
What's the point of trying to explain this outside of LKML?
Convince third parties? He needs to convince Linus in LKML, rather than this sad attempt at brigading.
The security features of android are the best argument for the stance Linus takes on these things.
Hmm does this only apply to files though? I'm talking about kernel signature engorcement on any page mapped into memory.
There is an argument that "it's useless"  without SecureBoot but so what? Separation of concerns is a good principle and allows external people to reason about the behaviour much more easily.
There is no point implementing logic like "if x == 0 then y = 0; return x * y" when a simple "return x * y" will suffice. In fact it's actively harmful as it raises the complexity.
Also, I am not sure about it adding no security without verified boot - a machine rebooting is something that can be noticed.
And the /r/linux discussion from earlier:
Will this parchset get merged?
> No way in hell will I merge anything like this.
> Linus 
I highly doubt it.
Lockdown mode itself is very likely to be merged.
It becomes clearer if you read http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01597.html which was linked elsewhere in the comments here.
Michael Garett seems to think lockdown without Secure Boot makes no sense. The kernel team seem to disagree.
I didn't get to a point where any resolution was met, but Linus did complain about over 100 emails wasted before a legitimate reason they should be linked came out.
That's not my name, but anyway. I don't think it makes no sense. I think asserting that it adds meaningful security in the absence of some other mechanism for gaining trust in the kernel is misleading, and I think the reduction in functionality associated with it isn't worth it unless you have that security benefit. As a result, I think having the default behaviour in a general purpose distribution be "Enable lockdown even if we didn't have any indication that we booted securely" doesn't make sense - more specialised projects may have a reason to do so.
Do you think it's possible to do security at all without being educated? You seem to be advocating "doing the right thing" for the user, but if the user doesn't know how to do the right thing himself then any hope of security is out of the window anyway.
But I guess that's not really the point you're making, and of course, in an ideal world native apps would be no more dangerous than websites anyway…
Apologies, my words get a bit scrambled now and then.
> "Just look at this thread. It took closer to a hundred emails (ok, so I'm exaggerating, but not _that_ much) until the real reason for the tie-in was actually exposed."
Considering Linus has been arguing in favor of the value of lockdown in lieu of SecureBoot he's obviously on-board with the patchset conceptually. The problem seems to be in how SecureBoot and lockdown are currently related in the implementation when he's arguing they're entirely independent of one another. The things just fall apart in the communications.
Except for it being tied to UEFI boot.
EDIT: Sorry for the confusion, I mean lockdown without Secure Boot -- I thought Linus was saying they were independent things, so I was trying to see how lockdown could work independently of Secure Boot.
1) Your kernel is in flash and your firmware won't update it unless it's signed. In that case the fact that there's no secure boot as such is irrelevant, because you can assert that the hardware is providing a root of trust anyway
2) Your firmware measures the kernel into something like a TPM and the TPM won't release a secret that's required to boot unless that measurement is correct. https://mjg59.dreamwidth.org/35742.html describes a couple of shortcomings in that approach and how you can get around them - if you do that appropriately, there's no risk
3) Your system has some other kind of verified boot implementation (such as ChromeOS)
But otherwise yes, that's the point - defaulting lockdown to on while it's still easy for an attacker to replace the kernel may not be a great default, because it removes functionality without offering much additional security.
Otherwise, on a more general-purpose computer with a writable /boot/, some verified boot like secure boot is required to ensure that your chain of trust is established.
It’s really far-fetched to believe it’s anywhere near possible to secure it.
A security feature that can be circumvented in many non-secure-boot cases is still a footgun protector. And there are already plenty of those. I'm not surprised the LKML thread pushed back as hard as it did. If that's his reason for digging in his heels, then suspicion that there could be more at play doesn't seem all that unwarranted.
Now replace Blizzard with any iOS application and you have the iOS AppStore ecosystem. We're already there. And I'm also pretty sure Blizzard and Apple have some dark back room deal like this, although it's more about Apple allowing Blizzards shit to do whatever it wants on its platform and less about methods of attestation considering everything is already in place for that.
What I'm saying is this already exists today. iPhone hardware can attest to the integrity of the running system because Apple practices secure boot and maintains a PKI (supported by the kernel and TPM) responsible for verifying the integrity of software running on its system. Apple can say to a Blizzard "game" with certainty (barring security vulns), "there is no unauthorized software running on this system".
And as far as Apple is concerned wrt their platform, Blizzard is just another app developer in their ecosystem. They don't have to pay a special "attestation premium".
What does that assertion even mean unless you completely lock down app signing keys though? Sure - this system doesn't run any unauthorised software, only "foobar test" signed by a valid developer key; everything is fine.
It works for consoles, because you won't have the trusted signing keys.
Anyway you're right that's besides the point now. My original point (rephrased to Linux) was that a desktop leveraging secure boot plus the recent work to harden the boundary between kernel and root plus something like (as you pointed out in the other thread) IMA could, I think, meet the original commenter's requirements.
1. I run a malware as root which modifies my image. I don't run anything as root except apt. So this is impossible.
2. Someone steals my computer and modifies the disk. Again, if they have physical access, I have already failed in my security. So this scenario is irrelevant.
Am I missing anything?
2. apt packages can run arbitrary bash scripts as root as part of their install and update process. Hopefully your third-party apt repo hygiene is good.
3. Just because you only explicitly run apt as root, does not mean no program runs as root. setuid executables exist and are unfortunately quite common in Debian.
I highly doubt it. Privilege escalation exploits are rare and fixed with utmost priority.
> apt packages can run arbitrary bash scripts as root as part of their install and update process. Hopefully your third-party apt repo hygiene is good.
Yeah, a root user should be responsible.
> Just because you only explicitly run apt as root, does not mean no program runs as root. setuid executables exist and are unfortunately quite common in Debian.
And I assume that when the root user installed those apps, he was careful and selective and did not include malware.
A statement which would be much improved with numbers. How rare? Fixed how quickly?
It's not about what you explicitly choose to run as root at the command line. That's a tiny fraction of the code that executes as root on your machine. It's about what software can do to somehow gain access to root's privilege level via exploits.
Yeah and that was a really big deal. Fixes were pushed in record time.
> It's about what software can do to somehow gain access to root's privilege level via exploits.
The correct way to deal with that is to plug exploits or write code that is less likely to be exploited. Taking away privileges from root is the exact opposite of what we should be doing.
Root access should be protected, and any bugs that break this barrier without the user's credentials should be fixed/prevented.
The root user should have absolute power to do anything. This is the basic ethos of Linux.
Taking away power from the user results in ios. I don't want Linux distros/systems to start behaving like ios.
>The root user should have absolute power to do anything. This is the basic ethos of Linux.
They're just splitting 'root' into two parts. No power has been taken away.
1. What if apt is compromised?
2. What if apt installs something which is compromised?
3. What if you run something which is compromised and escalates privilege?
Then fix it.
> 2. What if apt installs something which is compromised?
This implies apt is compromised. Goto above.
> 3. What if you run something which is compromised and escalates privilege?
If something is able to escalate privilege that's a kernel bug of the highest order and must be fixed asap.
Not without Secure Boot.
Really... why would I as user not want it?
At the same time, MS specified for ARM computers that want to run Windows that the key must be fixed and irreplaceable.