I'm always a little wary of technological innovations that stop the system administrator from being able to administer the system. I understand the concept of not trusting root, but the solution surely isn't “so make the manufacturer the real root”. There isn't even a hardware override for this!
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?
It's the administrator that enables or disables this feature, though. Laptops often come with some pretty advanced encryption hardware (the TPM) built in, and it's mostly useless silicon if you don't find a way to use it.
The kernel trusts the hardware it runs on to do what it's supposed to do, unless it has some good reason to apply security restrictions to a device.
_Real_ root turns on or off the hardware by configuring hibernation in lockdown or disabling it. Leave it disabled if you don't trust the TPM manufacturer, but I don't see a reason why not to use it to secure your operating system. Intel processors run a separate 486 CPU for scheduling reasons, there's so many potential security backdoors in the average laptop that I wouldn't worry about the TPM too much.
In the end, this is just another trick that Windows could already securely do for years that Linux only just learned. "Can I hibernate without compromising kernel security measures when Windows can" isn't a great question to have to answer with "no, because..." if you want to advocate Linux to businesses.
You put your computer into hibernation and walk away for a few hours, then come back and wake it up. Wouldn't it be nice to have a cryptographic guarantee that the image you are resuming from is indeed the same one you hibernated to? That takes away a possible attack vector.
Well, if you don't need Linux Lockdown, don't enable it.
The problem Linux Lockdown fixes as follows: Microsoft BitLocker stores its key in TPM which is accessible to Ring 0 code only. If the user would be able to run arbitrary Ring 0 code they could bypass BitLocker without actually knowing the password.
To prevent this, Secure Boot is being used which requires the kernel to be signed. To avoid the necessity for user to allow distribution key in UEFI settings, many Linux distributions sign their kernel using Microsoft keys and to make sure this couldn't be used to run arbitrary Ring 0 code (which could end up with Microsoft revoking their key). Linux kernel enforces various restrictions: no loading custom modules and so on.
Hibernation is complicated with Linux Lockdown as during hibernation, kernel loads contents of swap disk into RAM. Somebody could make their own Linux distribution, use a signed kernel from Canonical and make sure the bootloader would load their own malicious swap disk which would bypass Secure Boot requirements.
but the solution surely isn't “so make the manufacturer the real root”
I think it's pretty clear what features like this are designed for. The mobile ecosystem and their walled gardens, where the manufacturers --- and Google --- certainly do want complete control (and it's a little funny to see the power struggles between them), and treat the users as nothing more than consumption-slaves to be milked for profit.
...or when something that seems almost innocuous today, a processor serial number, caused such a huge amount of opposition that it was actually removed:
Now, users are getting dumbed down and herded in the name of "security", and losing more and more freedoms every day... while being almost completely unaware of it.
> "if you were root you could just replace the on-disk kernel with a backdoored one and reboot."
Isn't this a vital necessity? You want to be able to update the kernel to a new version, don't you? Preventing root from being able to do vital system maintenance sounds to me like the opposite of what you want.
If an attacker has become root, the system is compromised. As far as I know, security should focus on preventing an intruder from getting root access. Once the intruder gets root access, isn't it kinda pointless to worry about the kernel?
There's three things we really want here:
1) Prevent people gaining inappropriate privileges
2) Detect if people have gained inappropriate privileges
3) Prevent those inappropriate privileges form being persisted
If we can achieve (1) then (2) and (3) are irrelevant. If we can't, then (2) depends on the kernel being trustworthy (things like IMA and audit can give strong indications of compromise, but if the attacker can get into the kernel then they can just hide themselves), and (3) is much easier for an attacker to undetectably pull off if they can switch out the on-disk kernel.
Replace kernel with unsigned kernel where appropriate. They’re saying basically root should NOT be able to get to an unsigned kernel via swap/hibernation tricks. Who holds the keys is left up for discussion.
I'd absolutely love to use it on my secondary machine, a desktop PC running Windows 10 – just hibernate and pick up right where I've been a few days later without leaving it in standby blinking its super bright LED aggressively. Sadly if I send it to hibernate the PC will always turn itself back on in the night, so no hibernate for me...
Laptops, mostly, to maximize battery life. If I'm going on a flight, I'll charge and hibernate my system at home, bag it, then drive to the airport and get through security. This is about a 2 hours process and entails zero battery drain.
[+] [-] wizzwizz4|5 years ago|reply
Getting hibernation to work under Linux Lockdown is technically impressive, and now we know how it can be done. But should it be done?
[+] [-] jeroenhd|5 years ago|reply
The kernel trusts the hardware it runs on to do what it's supposed to do, unless it has some good reason to apply security restrictions to a device.
_Real_ root turns on or off the hardware by configuring hibernation in lockdown or disabling it. Leave it disabled if you don't trust the TPM manufacturer, but I don't see a reason why not to use it to secure your operating system. Intel processors run a separate 486 CPU for scheduling reasons, there's so many potential security backdoors in the average laptop that I wouldn't worry about the TPM too much.
In the end, this is just another trick that Windows could already securely do for years that Linux only just learned. "Can I hibernate without compromising kernel security measures when Windows can" isn't a great question to have to answer with "no, because..." if you want to advocate Linux to businesses.
[+] [-] rcthompson|5 years ago|reply
[+] [-] GlitchMr|5 years ago|reply
The problem Linux Lockdown fixes as follows: Microsoft BitLocker stores its key in TPM which is accessible to Ring 0 code only. If the user would be able to run arbitrary Ring 0 code they could bypass BitLocker without actually knowing the password.
To prevent this, Secure Boot is being used which requires the kernel to be signed. To avoid the necessity for user to allow distribution key in UEFI settings, many Linux distributions sign their kernel using Microsoft keys and to make sure this couldn't be used to run arbitrary Ring 0 code (which could end up with Microsoft revoking their key). Linux kernel enforces various restrictions: no loading custom modules and so on.
Hibernation is complicated with Linux Lockdown as during hibernation, kernel loads contents of swap disk into RAM. Somebody could make their own Linux distribution, use a signed kernel from Canonical and make sure the bootloader would load their own malicious swap disk which would bypass Secure Boot requirements.
[+] [-] mjg59|5 years ago|reply
You can always use mokutil to disable this.
[+] [-] userbinator|5 years ago|reply
I think it's pretty clear what features like this are designed for. The mobile ecosystem and their walled gardens, where the manufacturers --- and Google --- certainly do want complete control (and it's a little funny to see the power struggles between them), and treat the users as nothing more than consumption-slaves to be milked for profit.
[+] [-] ylyn|5 years ago|reply
[+] [-] etaioinshrdlu|5 years ago|reply
[+] [-] userbinator|5 years ago|reply
https://news.ycombinator.com/item?id=10106870
Now, users are getting dumbed down and herded in the name of "security", and losing more and more freedoms every day... while being almost completely unaware of it.
[+] [-] saagarjha|5 years ago|reply
[+] [-] TeeMassive|5 years ago|reply
[+] [-] heavyset_go|5 years ago|reply
[+] [-] mcv|5 years ago|reply
> "if you were root you could just replace the on-disk kernel with a backdoored one and reboot."
Isn't this a vital necessity? You want to be able to update the kernel to a new version, don't you? Preventing root from being able to do vital system maintenance sounds to me like the opposite of what you want.
If an attacker has become root, the system is compromised. As far as I know, security should focus on preventing an intruder from getting root access. Once the intruder gets root access, isn't it kinda pointless to worry about the kernel?
[+] [-] mjg59|5 years ago|reply
If we can achieve (1) then (2) and (3) are irrelevant. If we can't, then (2) depends on the kernel being trustworthy (things like IMA and audit can give strong indications of compromise, but if the attacker can get into the kernel then they can just hide themselves), and (3) is much easier for an attacker to undetectably pull off if they can switch out the on-disk kernel.
[+] [-] bombcar|5 years ago|reply
[+] [-] finchisko|5 years ago|reply
So, how does the localities of TMP, solve the problem of rogue root installing custom TPM kernel module, that have access to locality 1?
[+] [-] mjg59|5 years ago|reply
[+] [-] wheybags|5 years ago|reply
[+] [-] jeffbee|5 years ago|reply
[+] [-] dividedbyzero|5 years ago|reply
[+] [-] Karunamon|5 years ago|reply
[+] [-] eMGm4D0zgUAVXc7|5 years ago|reply
- With hibernation it is possible to store the hibernation file on the encrypted root partition so you will have to re-enter the password during boot.
- With suspend-to-RAM, it would always be in memory.
[+] [-] admax88q|5 years ago|reply
[+] [-] aritmo|5 years ago|reply