Hacker News new | past | comments | ask | show | jobs | submit login
Enable hibernation when Lockdown is enabled (kernel.org)
86 points by doener 12 days ago | hide | past | favorite | 54 comments





There's a more detailed background on this here: https://mjg59.dreamwidth.org/55845.html

> In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed[5] systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what's the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards?

I still think there's plenty of point. I usually don't care about what ring0 can do; I care about what the system can do. Root can steal or destroy my data, or make my system do bad things.

The reason for restricting what kernel will be loaded, is to restrict what will happen at userspace.

A common use-case is bitlocker-style encryption. The system decrypts my harddrive using keys from the TPM. My own userspace is secured at the userspace-level using a login prompt. To defend against an attacker sideloading a different OS, I rely on secure boot to only load my kernel and hence my userspace.

I'm actually having a bit of a hard time finding really good usecases for this lockdown feature. On embedded systems the secure boot keys are often fused in, but I suppose the kernel, but potentially not root, could be able to change the tpm keys on an x86 system?


> To defend against an attacker sideloading a different OS, I rely on secure boot to only load my kernel and hence my userspace.

You could additionally seal the TPM key to specific PCR values so that only booting your kernel would allow using that TPM key.

> kernel, but potentially not root, could be able to change the tpm keys on an x86 system?

Depends on what do you mean by "change". They can't extract private bits but they can remove and add new ones. But if the data is encrypted using the old key it would become bit recoverable.


> but potentially not root, could be able to change the tpm keys on an x86 system?

A non-root can change the entire TPM chip on an x86 system...


From "SecureBoot is hindering Linux" to "How we can exploit its feature set further, so we can make things even more secure". Wow.

I'm actually glad that Linux has found a way to use SecureBoot and build upon it. This is really impressive.

I still don't like the idea of being Microsoft is the only key authority, but well...


Isn't this moot given that with many BIOS interfaces you can choose your own root authority and not use theirs?

> I still don't like the idea of being Microsoft is the only key authority, but well...

anyone aware of companies building alternatives to this? If I'd be China, Russia or Iran I'd have a keen interest in avoiding letting my adversary manage attestation at all cost.


First thing I expected from the title was a nerdy article about sleeping through winter during a Covid curfew, hah!

It says: "kernel.org". The context is there.

Yes, the context is there to correct you right after you make the wrong conclusion.

That's not a complaint, by the way, I found it hilarious.


Has anyone ever carried out a sociological study about the "anthropomorphism" (for lack of a better word) present in computer science/the IT industry?

Finally, a practical use for TPMs that isn't DRM! One thing I'm curious about is if encryption is dependent on the current boot–if not, could an attacker steal the hibernation state, reboot into a kernel of its choosing with the right PCR state, decrypt and then re-encrypt an altered restore?

TPM is also used by BitLocker drive encryption, it enables passwordless encryption.

That's what "downgrade kernel" means in the mail. This patchset does not address that issue, but apparently there is a way to make it work.

How about using it to store your HDD decryption key? I thought that was the main use. Change the boot chain, and you'll have to type it manually.

The solution for that is Secure Boot. As far as I know TPM is aware of Secure Boot status being changed and will disable/wipe secrets when it happens.

Downgrade is an issue as previously signed kernels (before this patch) would be happy with userspace using that TPM config to decrypt the hibernation imagine.

As the previous kernels are already signed, downgrading to them is allowed under the Secure Boot, but booting a new version of unsigned kernel on that machine is not.


I don't really agree with this separation of privileges between root and kernel... (and by extension, lockdown mode)

It seems to add a lot of complexity, and offers no real world usecases.

If you want a secure system, don't run untrusted code as root! If your evil code only runs as a regular user, there is no issue trusting hibernation, because a non-root user will never be able to touch the hibernation image. Even if you assume the non-root user has physical access to the disk between boots, you can use disk encryption and TPM to ensure they can't mess with it.


> If you want a secure system, don't run untrusted code as root!

This pretty much means: don't run any untrusted code as any user (because privilege escalation) and that also pretty much includes visiting any web page.

Security flaws exist and they are in-fact being abused.

Not having to completely wipe a machine (if that even helps. Who knows what kind of tricks malware elevating its privileges to root can pull) after every day of web browsing is a nice convenience to have.


Malware running as root doesn't need kernel access to wreak plenty of havoc. Hell, your own user has access to almost all of the data that both you and the malware author are likely to care about.

Malware running as a normal user can't put itself in a position where it's hidden from software running as root.

Preserving system integrity was my point.

The patch in the original article is about preserving system integrity in the face of a compromised root account and the only way of doing that is by limiting the capabilities of the root user.

It adds one more and hopefully final level of defense in order to guarantee system integrity.


Yes, the security model based around users in Unix is very outdated at this point. It doesn't really represent the kind of threats a modern computer faces.

Relevant xkcd: https://xkcd.com/1200/

>This pretty much means: don't run any untrusted code as any user

Wasn't this a recommendation from Intel when spectre/meltdown happened?


> because privilege escalation

If we're assuming a vulnerable kernel, why not assume vulnerable firmware and throw the whole thing out?


> It seems to add a lot of complexity, and offers no real world usecases.

The use case for kernel lockdown has to do with being a good player in the Secure Boot ecosystem so that kernel images can be signed by default. If a malicious user can boot the kernel in secure boot mode and then get it to execute code in ring0 that chainloads a different OS while staying in secure boot mode and with the user being none the wiser, this subverts the ecosystem since the other OS will lose its pre-existing guarantees about system state. Note that the EFI "shim" executable does allow for chainloading an OS in secure mode but only after prompting the user to that effect.


Just make the linux kernel modify the TPM state in some way on startup? Then any chainloaded OS would be able to see it isn't running on bare metal.

Isn't that kind of a lost fight? So many signed bootloaders and no way to revoke in-the-wild.

And how do you propose to effect that? Because can you trust apt? Not really, but we just do. Can you trust that you're talking to the DNS server you think you're talking to? Again, not really, but we do. Can you trust that your admin won't violate their contract, and the law, for personal gain (or to prevent personal loss)? Still no, but again we typically do anyway.

The real world includes things like large infrastructure, hospitals, defence, etc. Separating root from kernel in those settings adds complexity because just having "be root" be your access pass to the everything has already been proven to not be good enough time and time again.


setuid breaks this thinking. For nearly 15 years, "beep" on Debian could be exploited to get root. "Don't write unexploitable code that runs as root" is not a solid defense mechanism for today's world.

> It seems to add a lot of complexity, and offers no real world usecases.

I'd love to be able to lock my system in a trusted state and try some dangerous things, having another level of isolation between kernel and root, as long as I have the keys to revert/modify the state.

This irks the old timers (incl. me) as "It's already secure when process doesn't have root, eh?", but containers, cloud, virtualization and other stuff makes these further enhancements useful. I'm not adding high security installations to this set of scenarios.

Linux is already pretty secure by most counts, but more security won't hurt IMHO.


> I'd love to be able to lock my system in a trusted state and try some dangerous things, having another level of isolation between kernel and root, as long as I have the keys to revert/modify the state.

You should take a look to QubesOS. It gives me peace of mind.


Due to namespacing, anybody can appear as root to the kernel, at least if unprivileged namespacing is allowed. So you kinda need the separation.

Is this true? While you can appear root to other userspace apps, I don't think any amount of namespacing will let you get capabilities to load kernel drivers...

> It seems to add a lot of complexity, and offers no real world usecases.

As sad as it is, there is one use case: DRM and other forms of device integrity attestations.


Exactly. Its main goal is to appease the authoritarian corporatocracy.

This is one of the biggest signs that open source does not mean freedom.


there is a of privilege association

*a risk

Why not simply require the hibernation image is stored on a LUKS partition?

Then nobody can tamper with the image, since the LUKS key is derived from the TPM...

Then you get to reuse all the existing kernel infrastructure rather than reinventing the encryption wheel...


> Then nobody can tamper with the image, since the LUKS key is derived from the TPM...

How do you avoid root having access to it?


Simply don't allow root to write to partitions that would be eligible for resume?

Ie. if it's swap on LUKS, writes are disallowed and resume can happen. In all other situations, writes are allowed, but resume cannot.

There isn't a thread safe way for root to write to a swap partition while it's in use anyway, and I'm not even sure if the current kernel allows that.


How do you suggest enforcing that root can't write to a LUKS swap partition? Root knows the key, root can write to block devices, what's stopping me from disabling swap and writing a backdoored image to the partition with a user-space implementation of LUKS?

At last ! Glad to see this incoming. Now if it could work also for LineageOS phones, that would be perfect.

Very interesting work, but I see 2 major weakness: (hinted at the bottom of the introduction)

> So. During hibernation we freeze userland. We then reset PCR 23 and

> extend it to a known value. We generate a key, use it and then encrypt

> it with the TPM. When we encrypt it, we define a policy which states

> that the TPM must have the same PCR 23 value as it presently does. We

> also store the current PCR 23 value in the key metadata. On resume, we

> again freeze userland, reset PCR 23 and extend it to the same value. We

> decrypt the key, and verify from the metadata that it was created when

> PCR 23 had the expected value.

First weakness: kexec. It's not clear how the extension of PCR23 will be compatible with different kernel versions. What if you want to upgrade in place and kexec your new kernel, to avoid too much time spend in the bios (as is often the case on systems with multiple disks and specific peripherals)? What if an attacker use kexec for more evil purposes?

Second weakness: kernel image attack. This work is interesting in that in provide a nice way to prevent a specific kind of evil maid attack (replacing the content of your swap by something evil), but the job of protecting the swap falls in the kernel.

If the extension of PCR23 is done with a common key (to help with the kexec - for example the UUID) or anything that can easily be guessed/recovered, it will be possible to cook an "evil" kernel that 1) extend PCR23 with it to get access 2) inject content into the swap before resume. It just moves the problems.

As most systems use a shimx64 followed by grub, it won't be detectable by the user.

The best solution I see:

1) secureboot with your own keys, using a fat EFI (kernel + initrd + cmdline in one EFI file) that you sign (cf https://wiki.archlinux.org/index.php/EFISTUB ; and to automatically deploy new kernel on apt upgrade, use a systemd monitor: https://wiki.archlinux.org/index.php/EFI_system_partition#Us... ) : the computer won't boot if this is altered

2) place what's used to extend the PCR23 in a luks partitions with 2 keys: a plain text one for recovery or transfer of the disk to another computer (or rescue operations etc), one stored in the TPM

You could also store in that protected partition the keys for other boot related task - just let the kernel key manager expire the key and have the final step of the boot unmount this partition. Even if it's 0700 and the file inside are readable only by root, you don't want a zero day to expose your keys


I wish someone would enable me to hibernate in lockdown :-/

The biggest issue are gut bacteria, a.k.a user space devices with their own energy supply that are not managed by the kernel.

Have you tried checking if you have the necessary FAT drivers? You may also want to try looking into dropping your core temperatures a bit.

Man, it would be legit amazing if we could just sleep off extra fat. If that would include a proper rebuilding of damaged tissues, just wow. Sleep will have to suffice for now.

To a degree this is what happens already. Just not generally fast enough to avoid putting in the hard work of exercising and diet. (In fact, muscle growth is you damaging your muscles with strenuous exercise and then the body repairing itself to a better state during your sleep.)

Fix your sleep is pretty good baseline advice for people starting fitness.


The FAT driver is definitely not a problem....

Mine is now abundantly ExFAT

Hehe I thought the exact same thing. Thanks for articulating

It's the waking up from hibernation that always seems to be iffy.

Sound life advice



Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: