umount ecrypted fs on hibernate

[DMoL]

Hello,

I've followed the guide [1], and successfully encrypted filesystem with sensitive data. Usually I don't reboot my notebook, but do hibernate-to-ram (aka put to sleep). I've noted that after wake up, the encrypted filesystem is still mounted. How can I umount it + execute "cryptsetup luksClose myname", when I press hibernate button?

I'm not sure, but my hibernating process is handled by "sys-power/hibernate-script" .

Thanks!

[1] https://wiki.gentoo.org/wiki/Dm-crypt

[Hu]

You can run commands before sleep using an OnSuspend NN /path/to/command hook in the configuration file for hibernate-ram. However, you cannot umount a filesystem that is in use.

[frostschutz]

There is luksSuspend/luksResume that works without requiring umounting. Read/write requests are simply delayed indefinitely.

If it's your root partition you won't be able to luksResume since trying to access cryptsetup binary will get stuck. So you need a kind of initramfs that still provides this binary...

[JeroenMathon]

I strongly do not recommend using hibernation while having disk encryption.
Mainly because the moment you are not close to your PC you will leave it vulnerable.

You also want to make sure to always shutdown correctly so that LUKS and dm-crypt clear the decryption key from RAM correctly.
If they cannot do that you can retrieve that key trough a cold boot attack.
Having it remain on the disk(I assume a unencrypted partition) is not smart because unless its securely wiped every time it will be easily recoverable(Especially when its on the boot partition which is rarely written on.

TL:DR Having your computer automatically put in the key after waking up from hibernation defeats the purpose of encrypting your computer.


EXTRA NOTE: If an attacker manages to modify the encryption program when your computer is decrypted(in use) to not securily wipe(Which should not be any danger when you remove the power and ram gets cleared because of power loss) then they can retrieve it from the hard disk using forensics tools.

[Hu]

Some of those concerns are valid, but I think you made two unfounded assumptions. First, OP mentions using sleep, which is typically implemented with substantial help from the system firmware. Yes, the key remains in memory. Yes, a cold boot attack could recover it. However, if the system is in sleep mode, it will not have written the key to disk, and when it resumes, control should transfer automatically into Linux. If OP has configured the system to lock the screen before sleeping, then an attacker could resume the system, but would then have no more access than if he found a locked and unattended desktop.

You can get reasonable safety using hibernate-to-disk with disk encryption if the hibernation image is itself written to an encrypted swap volume. Most guides should advocate this already.

Yes, there is a concern that an attacker could modify the system to compromise the decryption. However, this problem applies also when the owner halts the system and leaves it unattended. An attacker could replace the kernel, initramfs, or both with malicious versions. The threat model for encrypted disks has always been weak relative to the scenario that an attacker has an extended period of unsupervised access to the system when it is not running. TPMs were supposed to solve part of that, but were implemented in such a way that most people do not make sufficient use of them.