5 ms·
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 access
by GlitchMr 6y ago
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.
- baybal2 6y agoAnd all of this makes zero sense, given that anybody can simply tap the TPM chip itself. All x86 TPMs are effectively pwned, and useless for their stated application. TPM never served any real security role. Making a system fully secure against a physical attack is impossible, and looks plainly silly to anybody knowing how computers work. Even specially protected credit card chips cost only few thousand dollars to extract a key from in the numerous "firmware recovery" shops.
- geofft 6y agoWait - given that Ubuntu's signed shim/GRUB is willing to load unsigned non-EFI kernels, does that mean you can use it from a USB stick to unlock a BitLocker machine, without even messing with hibernation?
- my123 6y agoNo. BitLocker when it uses the TPM uses verified boot. PCRs are filled during the boot process, recording the boot state. If the boot state does not match, the TPM will not release the key.
- geofft 6y agoThen it shouldn't matter whether you can modify a hibernated Linux image to gain arbitrary code execution in ring 0, right? (That is, the benefit of securely implementing Linux lockdown hibernation would be a direct benefit for Linux users who care about lockdown and hibernation, as opposed to an indirect benefit for Windows / BitLocker users who don't want to be attacked through Linux.)
- my123 6y agoYes, the benefit of securely implementing hibernation with Secure Boot on for Linux is a direct benefit for Linux users, no impact one way or another for those using Windows.
- geofft 6y agoOK - that matches my understanding, that the threat model of BitLocker includes the possibility of attackers having ring 0 access using a different OS. I've downvoted the comment I originally replied to, since it appears to be totally wrong.
- bscphil 6y agoSibling comment says this doesn't matter because you can "just" tap the chip. I don't know if that's true, but practically, isn't the real reason why this doesn't matter is that there are a bunch of signed bootloaders that let you boot untrusted code? For example, famously, the Kaspersky rescue disk. [1] Even assuming that the key for this particular disk has been revoked, trusting this to protect your system seems rather fraught, as it's not good enough for your kernel to be secure from ring-0 privesc, every single signed image in the world needs to be as well. Could be I'm missing something. Is it impossible to replace the boot disk entirely once Secure Boot is enabled? Hard to see how the hardware failure case would be handled. [1] https://habr.com/ru/post/446238/ https://habr.com/ru/post/446238/
- my123 6y agoPCRs of the TPM. Combined with full drive encryption, the bootloader not matching will make the TPM not release the drive encryption key.