Enable hibernation when Lockdown is enabled
lore.kernel.org
lore.kernel.org
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?
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.
A non-root can change the entire TPM chip on an x86 system...
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...
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.
That's not a complaint, by the way, I found it hilarious.
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.
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.
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.
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.
Wasn't this a recommendation from Intel when spectre/meltdown happened?
If we're assuming a vulnerable kernel, why not assume vulnerable firmware and throw the whole thing out?
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.
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.
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.
You should take a look to QubesOS. It gives me peace of mind.
As sad as it is, there is one use case: DRM and other forms of device integrity attestations.
This is one of the biggest signs that open source does not mean freedom.
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...
How do you avoid root having access to it?
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.
> 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
Fix your sleep is pretty good baseline advice for people starting fitness.