> 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.
> 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.
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?
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.
> 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.
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.
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...
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?
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.
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
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.
