3 ms·

Because you mentioned secure boot and encryption: Matthew Garrett wrote an interesting blog post a while ago on making hibernation work with lockdown mode, i.e.

Because you mentioned secure boot and encryption: Matthew Garrett wrote an interesting blog post a while ago on making hibernation work with lockdown mode, i.e. verifying that the hibernation image wasn't tampered with. Otherwise it might be possible to get around the whole secure boot chain by writing a compromised kernel to a hibernation image. It's quite interesting to think about, even if it isn't necessarily something you as a user should need to think about (distros should probably handle it): https://mjg59.dreamwidth.org/55845.html https://mjg59.dreamwidth.org/55845.html

deckard1 6y ago
I read up a bit on this when I was setting it up. > What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot Maybe I'm just really thick, but I can't think of a reason to care that root could bypass secure boot. The attacker already has access to the entire system and I would usually assume the valuable part of that access is the data and not the hardware or the kernel. This is an attack at a level beyond the typical "evil maid" with physical level access. Besides that, I'm not sure what would stop anyone from just tampering with pacman, mkinitcpio, or other things and just wait until the next kernel is being built and redeployed to have their fun. You're going to have to upgrade your kernel at some point, and you'll need some kind of tools to do so. There's probably a very thin line between the threat that secure boot protects against and someone beating me to death for my password.
- lorenzhs 6y ago
  No, this isn't beyond evil maid - it doesn't require physical access, it only requires root access. Increasingly, root and kernel access aren't the same thing any more (if you enable lockdown mode). That stops root from doing a whole bunch of things. It's true that often, user-level access is enough (if you only care about the user's data). But if you want to modify syscalls or do some other thing that root may not do in lockdown mode, you'll need to get kernel access. And many other ways of getting there have been blocked in an attempt to strengthen the barrier between root and kernel (some dispute the utility of that separation, but I think it's because they fundamentally reject its goals). This is about closing another hole in the barrier. How useful that barrier is against attacks of the https://xkcd.com/538/ https://xkcd.com/538/ kind is, of course, a different matter. In my view, the point is that it raises the cost.

deckard1 6y ago

I read up a bit on this when I was setting it up. > What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot Maybe I'm just really thick, but I can't think of a reason to care that root could bypass secure boot. The attacker already has access to the entire system and I would usually assume the valuable part of that access is the data and not the hardware or the kernel. This is an attack at a level beyond the typical "evil maid" with physical level access. Besides that, I'm not sure what would stop anyone from just tampering with pacman, mkinitcpio, or other things and just wait until the next kernel is being built and redeployed to have their fun. You're going to have to upgrade your kernel at some point, and you'll need some kind of tools to do so. There's probably a very thin line between the threat that secure boot protects against and someone beating me to death for my password.

lorenzhs 6y ago
No, this isn't beyond evil maid - it doesn't require physical access, it only requires root access. Increasingly, root and kernel access aren't the same thing any more (if you enable lockdown mode). That stops root from doing a whole bunch of things. It's true that often, user-level access is enough (if you only care about the user's data). But if you want to modify syscalls or do some other thing that root may not do in lockdown mode, you'll need to get kernel access. And many other ways of getting there have been blocked in an attempt to strengthen the barrier between root and kernel (some dispute the utility of that separation, but I think it's because they fundamentally reject its goals). This is about closing another hole in the barrier. How useful that barrier is against attacks of the https://xkcd.com/538/ https://xkcd.com/538/ kind is, of course, a different matter. In my view, the point is that it raises the cost.