Lockdown Patches Merged for 5.4
lore.kernel.org/lkml/156968612114.18748.11996...Posted Sep 28, 2019, 4:45 PM UTC
20955
lore.kernel.org
I see bad things with OEMs enforcing lockdown for nefarious purposes without giving liberty to users. And you know thats going to happen.
I'm talking about practical applications here. From my own experience "unauthorized access" to the kernel usually means the user is trying to unlock a manufacturer-"secured" device.
I guess us plebs get to optionally enjoy a system safe from threats that doesnt (yet?) exist for us? Maybe 0-days from people who has the financial resources to go around this patch anyway e.g. the NSA or comparable Chinese intelligence? It already seems to have pretty limited application to regular people.
I dont think this is 100% on the best interests of regular users over corporations. Lets discuss this.
50
In the discussion about the iOS bootrom exploit, someone said "if you don't provide an authorized way to load your own trusted OS then people will find unauthorized ways to do it."
I sense that a similar thing is going on with lockdown. OEMs currently want a locked-down OS. If Linus declines to provide an authoritative and regulated way of achieving this, they'll write their own patches to do it. Users who would end up with a locked-down devices then could have an OS running an audited fully open-source kernel, or a privately developed fork of questionable quality.
Is it user-hostile? Of course it is; that's the point. Because the people asking for this don't see end users as the owner of the device. In that sense this patch serves the purpose of allowing the owner of a computer to have greater defense against potential attackers. It's just we're not used to thinking of the individual using the computer as an attacker.
26
Because the people asking for this don't see end users as the owner of the device
This is such a fundamental thing that it is mind boggling how few users are actually aware of this. There needs to be a way to communicate this to the users (especially the non-technical ones) in a way that is understandable to them so that they can understand how deeply it affects their privacy and freedom. I don't know, maybe display it as a message to the user when they're installing Linux or something.
15
From a corporate perspective.
If you didn't buy the machine, it is not your computer so your privacy is second to our security. This doesnt change even if you become a sudoer.
This is a good change. Plymouth should be used to splash the company logo on boot to remind the user its not their box.
7
"If you can't make ANY arbitrary change YOU want, you are not in control"
How does that sound?
3
Still bad.
If you dont have explicit ownership of the device it is not your machine.
2
[deleted]
1
Because the people asking for this don't see end users as the owner of the device.
Bacause they dont know better.
If they did, they would know this is just another thin ploy to take control of your shit, like everything else. Like people is already kind of waking up to, too.
No one would stand up to this if they knew what exactly this meant for their everyday use on their Android phone or whathaveyou.
4
To be fair Google's ChromeOS is locked down and worked out just fine. People know what they're buying and that the hardware is locked. They can always choose to buy unlocked hardware.
2
That hardware is not limited in any way. The whole system is very secure because its security is done well. But it is not locked down. The firmware is fully user replacable.
12
And you know thats going to happen, period.
You know that was going to happen anyway with or without this being in the mainline kernel so it might as well be there. OEM's are more than capable of patching the Linux kernel themselves, it's naïve to think that this not being in the kernel has actively held them back in anyway.
13
You know that was going to happen anyway it's naïve to think that this not being in the kernel has actively held them back
Yes I know, and It hasnt. I'm not pretending otherwise nor am I questioning their possibility to do so. Im positively affirming this will happen in my post.
Do we need to taint the software we use to free ourselves of precisely that because of this though? Fuck no, they can fork the Linux kernel and implement their own (hopefully exploitable) solution like everyone fucking else, or play by our rules.
Am I the only one in the universe who feels corporations should not even be wanting this merged in the first place?
17
Look at it this way, it's one (hopefully exploitable) solution that's publicly available instead of half-a-dozen whose source code may not be easily available. From the users perspective either way they're fucked if an OEM decides to go all authoritarian on them and prevent them from fully utilising their own hardware. It makes very little difference whether they're running a mainline kernel or some heavily modified kernel they're screwed either way. I agree with u/ima_wreckyou, the best way to prevent this situation is to not buy hardware from OEM's that do this and to try to convince others to do the same. As for tainting the kernel, it's already arguably tainted see the Linux Libre kernel from the GNU project if you want an untainted Linux kernel.
1†
Not buying this kind of hardware doesnt seem like an option anymore (again, name me one user-respecting and affordable alternative).
I do agree with you in the sense that an open alternative is better than a proprietary one, but a collaboration is harder to crack than a cheap proprietary implementation, no? Isnt that one of the reasons why Linux is the more secure option when compared to proprietary alternatives?
13
The right thing to do here is to simply not buy this devices.
2
Name me one affordable device that would be affected negatively by this patch, but also respects my privacy and freedom.
I would vote with my wallet if I could but that doesnt look like its a thing anymore. My computer runs IME even though I built it piece by piece and I can still choose which OS goes in it. Theres exactly nothing I can do about that even if I was running linux-libre.
16
I don't understand what those issues (yes they exist and are seriously bad) have to do with the patch set. Those are completely different things. Or maybe I just don't understand what you mean.
0†
I don't understand what those issues (yes they exist and are seriously bad) have to do with the patch set.
Ill try to break it down, ask me if you need more clarification:
This is code that will directly enable corporations to enforce those rules and also cooperate on strenghtening those restrictions. This is not okay. Period. Thats what I'm saying in essence.
You know whats worse? They are hijacking our "philosophies" so to speak and our way of collaboration for better and freer software for their crappy Owellian for-profit purposes.
Thats what this is and thats why people hate such efforts with such passion (and dont let it happen either).
DRM, yes I see why the current business models need it and why it needs to be in our everyday software. The point is: the current business models suck for everyone except the ones who profit from it.
Free software needs to be aligned to what we need, not what corporations need. Thats why we call it free software. And completely and utter FUCK them for wanting to even take part of that beautiful thing just so they can corrupt Linux for their own profit and selfish reasons.
Yes, thats the way the world works. No, we should not stand for that.
Edit: I'm still waiting for anyone to name me an affordable libre alternative for shit we need to use.
6
Good reason to switch to AMD
-5
Look "AMD PSP" up.
They are very likely doing the very same thing as Intel. They could prove us otherwise at any second now by opening that code up, curiously they wont without extensive review and preparation. A separate hypervisor running without your explicit knowledge on a computer you supposedly have control over? Nope, fuck off, not any better.
nvidia does similar things when it comes to the documentation that allows their hardware to run without attached strings. Shoutout to the sadistic Nouveau mantainers.
Dont get me wrong, if I had to upgrade today I would go for AMD over Intel, but eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeehhh.
9
Usually consumer products that try to restrict the firmware has disabled root access so nothing these patches do will change anything. This is aimed at securing web infrastructure where you want to give users more access without the possibility of manipulating the kernel.
If anything you might be given more access to restricted devices than you already have.
2
and we use stuff like kexec to "unlock" those same devices.
will that be a thing with lockdown?
1
You still need root access. Also CONFIG_KEXEC is usually disabled in those kind of devices, for obvious reasons.
1
This is the way all OSes are heading, especially with userland sandboxes. There needs to be some degree of isolation because virus scanners (really just "attempt to find bad code" scanners at this point) are just an arms race that we'll never win. It's much better to just isolate and sandbox all apps and let them do whatever inside that sandbox. It's especially become more important with VM based hosting via Azure and AWS; Linux is gonna start being more of a target as it starts hosting more of the world's internet websites.
Heck, even running WSL2 on Windows makes Windows itself run as a VM alongside Linux.
There's nothing currently preventing an OEM from making their own locked down kernel, not even the GPLv3 prevents permanently burning the OS to ROM.
Of course there's the argument of "why not just make a semi-root account with these restrictions" but a TON of people still think "it's MY machine, I should be root, why should I have to sudo anything on MY machine" (same with people running as admin on Windows because "hur dur i don't want to be a LIMITED account on MY hardware). It's easier to just say 'we can now optionally sandbox root away from these attack points".
1
There's really no need to discuss your FUD.
-1
Oh alright thats it then, sorry.
1
I think locking down the kernel would be very interesting, but blocking hibernation sucks. Will this be configurable? I already have my swap partition encrypted, and I'd like to continue using Secure Boot without having hibernation disabled.
17
Yes, it is configurable. It breaks a lot of really useful features like eBPF so it's a pretty situational feature, just like SELinux.
21
Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf:
Restrict bpf when kernel lockdown is in confidentiality
mode") is missing a Signed-off-by from its author. Matthew
responded that he is providing this under category (c) of the
DCO.
The what?
11
Developer Certificate of Origin, it has to do with maintaining patch attribution (i.e. SoB lines). With it you're essentially saying you're not pushing copyrighted code into the kernel and you have authorization to push it.
12
Developer Certificate of Origin
Since when is that required? I remember having to sign one in order to get patches into Samba, but not for the kernel.
4
That has been there for a long time, it is part of the initial git import 15 years ago.
I think you might confuse the DCO with a contributors agreement with copyright assignment. The DCO only requires you to declare that you have permission to add the code to the kernel and license it as GPL2.
The only real change to the DCO was in 2005 to add an explicit permission to retain personal information that is necessary to validate the license as Section (d)
11
I think you might confuse the DCO with a contributors agreement with copyright assignment.
No.
The DCO only requires you to declare that you have permission to add the code to the kernel and license it as GPL2.
But normally it’s accepted implicitly by merely submitting a patch, right? The odd thing is that this time it had to be pointed out as though it were a different thing from adding the SoB tag.
3
Awesome! More security options are always welcome :)
5†
[deleted]
0†
User has the freedom to enroll his own keys to take control over secure boot. It's in the spec, all motherboards I saw allow to upload your keys and decide what to boot. Why this freedom to boot only what you had signed yourself is bad?
Or are you meaning by "trusted computing" existence of Intel ME, AMD PSP and ARM Trustzone?
23
User has the freedom to enroll his keys to take control over "secure" boot.
But currently, the Linux images are signed by Microsoft because most motherboards, especially OEM ones, only accept such payloads.
Why this freedom to boot only what you had signed yourself is bad?
Because no one (that knows how to use a PC) is stupid enough to demand verification for their operation.
The reality is that such "security" measures are only useful for OEMs to restrict what you can do with your PC (Personal Computer) so you no longer really own it.
The user should be allowed to run any code at boot if he has physical access (which is what those "security" functions trying to restrict).
Seriously, this is the reason why UEFI exists in the first place: restrictions.
2†
But currently the Linux images are signed by Microsoft because most motherboards, >especially OEM ones, >only accept such payloads.
Of course, as by default all motherboards have Microsoft public keys, so bootloader/kernels have to be signed by it. They can't know your public key in advance. Even the OEM motherboards allow you to erase Microsoft keys, load your own and after that you have to sign bootloader or kernel yourself. Motherboard won't be certified as Windows-compatible if it doesn't allow user to override secure boot keys.
15
This is so uninformed..
For personal use:
The security is for validation to the end user THAT NOTHING HAS BEEN TAMPERED WITH SINCE LAST TIME.
IE: that password entry screen to login or decrypt the disk is trustworthy.
For corporate use:
See the above AND to complicate the process required for non-owners (ie the end user in possession of the device) from pwning the device.
OEM vendors dont accept anythimg other than MS signatures
This depends on device, the spec permits enrolling and trusting your own shit. Whether the device permits this or not depends on what the device is. Not permitting this enrollment is the problem, not secureboot or UEFI themselves.
14
Sorry, but you have no idea what you are talking about. Secure boot, TPM modules and this feature are fully controlled by the users on PCs and laptops. These technologies are needed to protect yourself against various kinds of attacks, for instance "evil maid" style attacks. They can also help to secure your personal crypto keys.
Some of those technologies can also be used by device manufacturers to restrict what are you allowed to do, that's true. The right solution here is to not buy those devices. It's not a problem with technology as-is.
9
[deleted]
3
I don't see it being enabled by default on any distribution soon simply because it has the potential to break so many things
1
It's been enabled by default in most major distributions for years.
2
So all distributions were maintaining their own patches until now?
1
Different distributions were carrying different variants of the same patches, yes
2
Guess I learnt something new today, thanks
1
[deleted]
-2
No, if you want to use the feature you will have to upgrade to 5.4+ kernel. Major features are not backported to LTS kernels, only bugfixes. There are very rare exceptions like speculative vulnerabilities mitigations when big chunks of code were backported, but the lockdown isn't worth it.
Outside kernel.org community this is possible, especially since Red Hat is interested in it, and Red Hat does it's own private backports of major features.
2
First was DRM at the HTML Standard level. Now this.
Is this it? Did we lose?
-2†
How is giving the user options to lock down kernel features that could allow modifying the running kernel and/or reading data that could be considered confidential anything like DRM? Nobody forces you to use this feature. It can be turned off just as easily as it can be turned on. If you just enable it in the kernel config, by default it does nothing. That's right, nothing. You turn on the actual lockdown with a simple kernel command line argument or changing a parameter in sysfs. Of course, you may also set a different default option in the kernel config, but most distros will not do that.
I don't really foresee any reputable PC OEM forcing this on and disallowing Secure Boot changes altogether, that'd just bring them bad publicity. Besides, since when is "it could be abused" an excuse for not having a genuine security feature in the kernel? This is perfect for users that are using Secure Boot with their own keys and who are already using every conceivable security feature to enhance their security further.
12
This feature allows you to voluntarily lockdown some unsafe kernel and hardware interfaces, so that malicious userspace programs cannot easily compromise your system, even if they are running as root.
There is no reason for spreading unsubstantiated FUD about this.
8
that's like saying being able to chmod is losing.
3
Is there an ELI5 explanation of this feature anywhere? The linked email only mentions the detailed changes from the last proposal.
LWN did a writeup on it https://lwn.net/Articles/750730/
Linux journal covered this in detail in a latter article that addresses a wider audience about some of the reasons for this long and passionate debate. Most noteworthy being the insistence of the original proponent of the patch, Matthew Garrett, trying to combine UEFI Secure boot with kernel lockdown in the pretext of a "more secure" system even though many felt they were not related and questioned his true motives. Check also the original mailing list.
Thanks.
How did it go from "No way in hell will I merge anything like this" to "[I] went through the security pulls yesterday and this morning, and found nothing objectionable. So it's merged now."?
I think the first major change announced in the link OP provided had a big role to play:
Even at the end of the discussion last year Linus set the exact phrasing of the problem that is acceptable to him and it was not the way Garrett initially presented it (which probably caused most of the tension):
No, Matthew Garret wanted to merge a patchset that included it, but the patchset required secureboot to be enabled for lockdown to be enabled.
Everyone else wanted to be able to enable either of the two things independently.
Everyone else won, so now this is being merged without a dependency on secure boot.
The other way around; the old patchset's recommended kernel setup force-enabled lockdown when running in Secure Boot. You could still enable it with a cmdline flag, but you couldn't disable it with one. So in practice your kernel would behave wildly differently based on a completely unrelated flag and we'd end up with advice like "disable Secure Boot if you want to install [Wireguard/ZFS/non-distro nvidia kernel drivers], do certain types of tracing, certain types of firewalls, use some hardware with weird DMA, ...".
This is now fixed by making it an opt-in after the system boots. We'll probably see an eventual move to signed initramfs and distros force-enabling it in their signed initramfs, but whatever.
Didn't he loudly announce a departure from the project a few years back?
https://www.zdnet.com/article/matthew-garrett-is-not-forking-linux/
[deleted]
I have to agree with Matthew Garrett here. It does make a lot of sense to combine secure boot with lockdown. Lockdown is a bit of a toothless tiger without secure boot, since you can still load arbitrary kernel modules, which can do whatever they want.
For instance, writes to CPU MSR registers are not allowed in lockdown. But you can easily circumvent this if you build a simple kernel module that does the writes, and then load it.
So if you use lockdown without secure boot, it'll give you a false sense of security without any extra measures (e.g. completely disabling kernel modules).