It tends to specifically be an issue with encrypted swap, because encrypted swap uses a random ephemeral encryption key. Honestly, I think in a lot of cases it makes sense to simply There are solutions for this: https://help.ubuntu.com/community/EnableHibernateWithEncrypt...
I think the real challenge here is for distro vendors to figure out how to provide a better user experience around this. There's no reason that the ephemeral key can't be stored in a sealed state that can be recovered as the machine wakes. There are obviously some security implications to this, but I think it's fair to say that a lot of users would prefer making that trade-off.
There's a lot of security models that rely on RAM being more difficult for an attacker to access than disk (as you can imagine it is much easier to ensure things stored to disk are resistant to compromise than to ensure that nothing in working memory is usable by an attacker). Swap is that in between case where storage is memory, so that creates a unique challenge.
What you want is that if someone steals your hibernated laptop, that absent a way to securely authenticate themselves as you, they can't restore the working memory of your laptop. If you think about it, if they could, much of the point of many security precautions would be lost.
Ah of course, I haven't thought about it that way, thanks for your explanation.
I guess it depends if you're willing to put all eggs in one basket so to speak. But instead of disabling hibernation outright maybe distros can find a compromise there.
My anecdotal experience with friends that tried Linux is that it left such a bad impression when they opened they're laptop the next morning and it's lost most of its battery life that some actually went back to Windows.
I think you may have missed what was being asked? I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key?
As a Fedora user, this is how my disks have been setup for many years, and I don't understand why Fedora have disabled hibernation. During wake from hibernation, the kernel and boot ramdisk would need user input to unlock the PV and to decode the LVs. Then, the hibernation state would be visible at the same time as the other filesystem state, and the kernel could decide whether to load the hibernation image or continue a normal boot sequence.
This seems to provide the protection of content needed for theft of a hibernated machine. I don't know whether there is some unhappy sequencing flaw in the dracut-generated ramdisk (between when the wake-versus-boot decision has to be made and the LVM decryption is done), or, whether someone at Fedora has decided that the threat model is different than we discuss above?
> I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key?
Again, the reason why it's different is the security model for memory is different from the filesystem. This is exactly what I was getting at: the fixed key. Encrypted swap volumes typically are set up to use ephemeral keys that are "forgotten" when you power down. The idea is that you only have access to that memory while the computer is running. When you boot up again, whatever data is in the swap partition is just noise. As mentioned in the link I provided (https://help.ubuntu.com/community/EnableHibernateWithEncrypt...), the current solution is to switch to using a fixed key, much as you described. That fundamentally changes the security model, and not in a subtle way.
I think there's a solution that more closely approximates the security model, with only a minor compromise: when you boot up, you generate an ephemeral key in the secure enclave, and use that to encrypt your swap. When you hibernate, the secure enclave encrypts all the metadata (including the ephemeral key) into a sealed state that is stored on disk with the swap information. When you restore, the sealed data is read back into the secure enclave (and erased) and it can then decrypt swap as needed. This still means the hibernated memory state is fully recoverable by whomever is able to authenticate with the enclave, but that's what everyone wants. On the upside, if you shut down the machine (rather than hibernate), the ephemeral key is lost, so there's no way anyone can recover what's on your swap, even if they have access to whatever fixed key(s) you have used for your LVM volumes.
If you're really paranoid, you could even generate a new ephemeral key on restore and reencrypt the entire swap volume with the new ephemeral key, though I'd question what realistic threat model that would really address.
Maybe we're not talking about the same scenarios/alternatives? If I've set up whole-disk encryption with a security level I trust for my persistent storage, how is that not appropriate for the persisted hibernation state? To me, hibernation state is a subset of persistent storage needs, not some categorically different thing. The coupling between running system and persistent state seems so strong to me that I consider them one equivalence class of data and requiring one consistent protection standard.
I adopted the conveniently offered, software-based whole disk encryption mode when installing Fedora. A luks-encrypted LVM PV is the only luks mapping at runtime, and a naked /boot volume is the only volume not allocated as an LVM LV in that encrypted volume group. Thus, I have selected my storage security posture. I expect the cold or detached storage device to be resistant to inspection. Due to the unencrypted /boot, I have doubts that there is tamper-protection of the future running software, should I temporarily lose control of the physical device. I have no illusion that the running kernel lacks access to the plaintext content.
My swap is an LV in that encrypted volume group. Why is hibernation disabled on Fedora? This is where I feel like there is a poorly communicated threat model or some other unstated assumption that I do not appreciate. (But see my last paragraph below for a possible answer!)
Are people concerned about the written hibernation state using the same key as the filesystem volumes? I.e. that knowing how to unlock the whole-disk encryption means you can reconstruct the hibernated image too? I don't see why I, as a user, should care to protect the hibernation image even more than all my regular data. Similarly, if I have the key I can potentially attack the root volume (while offline) to inject all sorts of malware, such that I could exfiltrate RAM state from the running system in the future. Swap isn't required to open me to that attack.
Are people concerned about regular swap state being available on disk during system operation? I.e. the running Linux luks mappings can be abused to inspect swap state? I am not sure I can appreciate this angle, since I think it is farfetched that the swap mapping can somehow be more resistant to attack than the filesystem mappings in the same running kernel.
Are people concerned about regular swap state being left on disk during a non-hibernated shutdown? If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto. Add an ephemeral cipher to swap if you must, but use framing/metadata to reliably distinguish the ephemeral swap "noise" image from a valid hibernation image. I'm OK saying that hibernate must write an entire image and not assuming that regular swapping can opportunistically prepare any hibernation state prior to a hibernation event actually commencing.
While writing all this, I have thought up another possible angle. Maybe this is the actual Fedora issue? I can see that control of an offline hibernation image means control of a future running system image, and this might violate some secure boot agenda? I.e. I can tinker with the hibernated state to introduce a "hacked kernel" and ask the system to restart with that. I can see why secure boot might prevent return from hibernation. This requires some integrity-protection chain to enable the trusted bootloader and kernel to verify a hibernation image before opting to load and restart it. I can see how a variation on your "sealed state" approach could address this. But note, it only requires integrity protection and does not actually need another layer of confidentiality protection.
> Maybe we're not talking about the same scenarios/alternatives? If I've set up whole-disk encryption with a security level I trust for my persistent storage, how is that not appropriate for the persisted hibernation state? To me, hibernation state is a subset of persistent storage needs, not some categorically different thing. The coupling between running system and persistent state seems so strong to me that I consider them one equivalence class of data and requiring one consistent protection standard.
Yes, we are talking about different scenarios. As I said, you can absolutely set up your swap to use a fixed password and then it will work fine as you describe.
> Are people concerned about the written hibernation state using the same key as the filesystem volumes?
That might be part of the concern, but it's more that it is possible to recover previous memory/swap state with a key that can reasonably be subsequently recovered.
Let's imagine a scenario where I have a secure password, that I enter into my browser, to say, access my bank's website. That's stored in memory by my browser & the GUI, but it is not normally allowed to be put on disk for security reasons. Then I hibernate my laptop and it gets written to the encrypted hibernate volume that uses a fixed password. I restore my laptop and go about my business. I might even reboot the laptop several time subsequently without thinking much about it. Then, someone finds a way to compromise the password used for swap encryption using any number of possible attacks (some you described). Now, not only do they have access to all the stuff on my computer, but they also have access to the contents of the encrypted swap volume, which unless I was lucky and the particular swap page was overwritten, the compromise goes back to the memory of the runtime from long before the machine was compromised. This would include this password that was very intentionally NOT stored on that computer, in order to avert precisely this kind of threat.
> If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto.
That's another possible avenue, not that unlike what I was suggesting. It's worth noting though that these days there may not be much value in having separate passwords for swap vs. hibernate, since swap is rarely used on laptops.
They are all different security trade-offs, and it is debatable which is the right one. I don't think the current default is the right one for most users, but I do understand it.
You definitely can. Actually relatively simple if you know your way around Linux. This is a good guide for Arch [1]. I think there's a couple more steps on Fedora or if you're using zram in general but it's definitely doable. I've even got it working with secure boot using my own keys.
I just went through this process with Gentoo on a framework laptop. Here are some random, likely incomplete notes to make this work. It uses a swap file on an encrypted filesystem
1. Create a swap file. Our rule of thumb is ram + sqrt(ram) for hibernate
fallocate -l 72GiB swapfile
chmod 600 swapfile
mkswap swapfile
swapon swapfile
swapon --show
2. emerge suspend
3. Get the number to use with resume_offset later. In the current case, it was 125798400
swap-offset /swapfile
emerge sys-boot/grub
grub-install --target=x86_64-efi --efi-directory=/boot
vim /boot/grub/grub.cfg
timeout=5
menuentry 'Gentoo Linux 5.18.19' {
root=hd0,1
insmod all_video
linux /kernel-5.18.19 root=/dev/mapper/root resume=/dev/mapper/root resume_offset=125798400
}
4. Fix suspend.conf
vim /etc/suspend.conf
resume device = /dev/mapper/root
resume offset = 125798400
5. Setup an initramfs
cd /usr/src
mkdir initramfs
cd initramfs
mkdir -p bin dev etc proc sys new-root
cp -a /dev/{null,console,tty} /usr/src/initramfs/dev/
cp -a /bin/busybox ./bin
cd bin
for i in `./busybox --list`
do
ln -s ./busybox $i
done
cd ..
cp -a /sbin/cryptsetup ./bin
mkdir -p ./run/cryptsetup
lddtree -l /sbin/cryptsetup
Copy in all of those files until the local cryptsetup works appropriately
vim init
#!/bin/sh
# Define a rescue shell
rescue_shell() {
echo "Error in boot process, dropping to a shell"
exec /bin/sh
}·
# Mount our devices. We sleep prior to dev to hopefully finish loading.
mount -t proc none /proc
mount -t sysfs none /sys
sleep 2 && mount -t devtmpfs none /dev
# Decrypt the root partition
cryptsetup --allow-discards luksOpen /dev/nvme0n1p2 root || rescue_shell
# Attempt to resume
printf '%u:%u\n' $(stat -L -c '0x%t 0x%T' /dev/mapper/root) > /sys/power/resume
# If we're not resuming, mount the new root
mount -o noatime,discard -t ext4 /dev/mapper/root /new-root
# Unmount (cleanup) our devices
umount /proc
umount /sys
umount /dev
# Boot from the unencrypted partition
exec switch_root /new-root /sbin/init
6. Suspend should be working with:
echo shutdown > /sys/power/disk
echo disk > /sys/power/state
or preferably
loginctl hibernate
Anyway, there's a lot of missing detail in there, but the idea is that there's a swapfile inside the normal encrypted root partition. For me, I've enough ram where I don't really use swap unless hibernating, so a swapfile versus a separate encrypted swap partition suffices.
