Slashdot Mirror
Torvalds Opposes Tying UEFI Secure Boot to Kernel Lockdown Mode (phoronix.com)
An anonymous reader quotes Phoronix:
The kernel lockdown feature further restricts access to the kernel by user-space with what can be accessed or modified... Pairing that with UEFI SecureBoot unconditionally is meeting some resistance by Linus Torvalds. The goal of kernel lockdown, which Linus Torvalds doesn't have a problem with at all, comes down to "prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded." But what has the Linux kernel creator upset with are developers trying to pair this unconditionally with UEFI SecureBoot. Linus describes Secure Boot as being "pushed in your face by people with an agenda." But his real problem is that Secure Boot would then imply Kernel Lockdown mode... "Tying these things magically together IS A BAD IDEA."
Essentially what the corporations want is for people to only user the Internet via locked down ("approved" or "secure" devices). These devices will only have cloud based storage available and everything will be streamed from servers and the consumer will only need to pay a monthly fee for all this goodness. If you don't think this will happen, think of the children, or the terrorists, or the terrorist children, or security, or whatever the problem is this week.
What does any of this mean?
That's not what the argument is about. UEFI SecureBoot has its place and reasons although an open implementation would be much better, Linux Kernel Lockdown has its place and reasons. Requiring one to enable the other is a problem or declaring that your system is broken without both enabled is a problem.
Custom electronics and digital signage for your business: www.evcircuits.com
"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." -Torvalds
Linux is a distribution by users, for users. So the individuals you are locking down are the developers and future developers of the operating system.
"Keeping the bad guys out" is a nanny state problem for for-cost operating systems. You can tie secure boot and kernel lockdowns together if you want to outsource your I.T. to a third party or for-cost developer.
The rest of us what to know what the difference is between what secure boot protect, and what kernel lockdowns protect. As well as to be able to enjoy our hobby without having to get a degree in cyber security to sign a kernel every time we want to try out a new OS or distribution.
Lock your house so people can't get to your computer. Kernel lockdown is about keeping control of your own system. Tying It to secure boot, though, is about keeping whoever has possession of the system (you) from having total control of it.
Secure boot ensures that the kernel can't be modified prior to boot. Thus it eliminates a false sense of security. The goal is to ensure that an attacker with temporary physical access to a machine cannot compromise it fully.
The question is what need or benefit is gained by having these two features intrinsically linked on the back end?
Thus it eliminates a false sense of security.
I suspect you meant emanates there, mostly because I've just reread one of Bruce Schneier's essays.
Inheritance is the sincerest form of nepotism.
You are in the wrong article..
Try again.
I bet you dream of being his toilet.
The goal is to ensure nobody has full access to modify the system.
FTFY.
uefi secure boot won't "keep the bad people out" either. In fact, uefi secure boot is a vehicle to take control away from you-the-computer-owner, and as such is the vehicle of bad people looking out for themselves using your hardware.
First, kernel lockdown in no way restricts which drivers you might have running. If you want to *change* which drivers you have running without rebooting, you'll need to *sign* the new module. Absolutely nothing prevents you from signing an open-source module. The command is:
scripts/sign-file sha512 kernel-signkey.priv kernel-signkey.x509 module.ko
(Or just set check the box to sign all modules in make menuconfig).
Sign-file signatures work for both secure boot and the kernel restriction. For the kernel, the first time you ever sign a module you enroll your public key with keyctl.
How stupid can this be? You put everything on ROM. No time wasted 'loading' this and that. Who thought that shit up to begin with? A computer should always be in a ready to run state, just apply power.
That is an argument for having the ABILITY to use secure boot with a locked down kernel (Linus is fine with that). It is not an argument for why the kernel MUST be locked down if you use secure boot. The latter is what others are arguing for without providing Linus a good reason.
Plus, there are other ways to solve the secure boot problem. For example, some systems I use boot from read-only media. Those would still benefit from the runtime protections of kernel lockdowns, but only one mention of that or other methods of securing boot by either side and the pro side for tying this to secure boot just blew it off with a "but how common is that?"
The key only needs to be available while installing a new kernel (not all the time), and only on one system in your organization.
Without the protection:
At any time, any system on your network can have kernel-level code changed, from userspace.
With the protection:
Before you deploy a new kernel across your network, plug your USB stick with key into your build system in order to allow dkms to build and sign the module. Then unplug the stick so that your kernel can't be changed without you doing it.
It gives you control of when and where your kernel can be changed, by dkms or any other program.
Nanny state to ensure your HIPPA and PCI and SOX compliant servers at work do not have rootkits?
If a system is rooted once a computer is booted then a few things MUST be true:
1. You've already epically failed. It's game over right there and then. Talk about what happens next is mightily irrelevant.
2. See 1.
3. See 1.
4. Unless vulnerability is found and fixed secure boot won't do shit to prevent the rootkit from being re-loaded upon next boot the same way it was loaded initially.
I very much fail to see the point here. The only conclusion I could draw that would make any sense is when you get owned you can get away with tempting fate and not have to completely rollback system / rebuild all of your shit otherwise secure boot seems to be an exceedingly pointless waste of time.
There is a much easier and much more secure way to handle this that does not require any cryptographic bullshit. Deny capability to modify OS image via hardware latch and don't allow any hardware to incorporate persistent storage that can be modified in the field.
The real reason for secure boot isn't security. It's exclusively about locking out users in order to dictate terms.
IT departments require UEFI secureboot with custom add in keys for their servers which Redhat and FreeBSD support I may add is to make sure you keep your job.
Box checking jobs sure do pay well regardless of predictably feckless results.
Serious question though - how do you as a Linux user protect physical security of the machine - say in the event someone breaks into your house/office without your knowledge, and installs a bootkit?
I remember the guy who discovered all the Mac "ThunderStrike" vulnerabilities said in a presentation - Secureboot would have protected against that attack - and that was a vulnerability that could have been applied in the time it takes for you to turn your head at a coffee shop, talk to someone and turn your head back to continue using your computer (which is now compromised).
Well now Microsoft is investing more and more into open source and putting out linux updates like a champ, we might say they really care about what will happen. In this regard I can suggest the outcome that if L.T. does not bend (and he usually does not) they might even fork to ensure they have their version of linux the way they want it.
Using tons of evidence Thomas Piketty points out in his book Capital in the Twenty-First Century that capital will naturally always grow at a higher rate than the rate of economic growth (read: wages).
From Wkipedia: "The book's central thesis is that when the rate of return on capital (r) is greater than the rate of economic growth (g) over the long term, the result is concentration of wealth, and this unequal distribution of wealth causes social and economic instability."
The rentier capitalist state is pretty much a done deal IMHO. The software subscription model being but a single case in point -- not to mention the cloud.
Remember the property grab during the last bubble burst? For those who are prepared with lots of cash these deflationary episodes are a peak opportunity. Market makers do their best to engineer them periodically (but not too often) to get equity at fire-sale prices as well as to scoop up real property, which can be rented, mined, developed, farmed, resold etc. Real estate is especially attractive in the long run because in the end there really is only land -- as any aristocrat will tell you. Control the land and you control.... everything. A few more bubble bursts and voila! Eighteenth Century France.
"No fear. No envy. No meanness." Liam Clancy
Why should Trump be tied to a prison toilet? He isn't under investigation for criminal activity.
I'm not a security whiz, but maybe with heads?