encrypt on suspend

[derDieDasJojo]

Expected behavior:

When my computer is in suspend mode it should also encrypted

Actual behavior:

in suspend mode the disk is decrypted

General notes:

with luksSuspend it should be possible to encrypt the full disk encryption, so after resume i have to reenter my full disk encryption password to access my qubes system again. also see the discussion here: https://askubuntu.com/questions/95625/suspend-to-ram-and-encrypted-partitions

[schnurentwickler]

It seems the make sync() functionality needs to be compiled into kernel. (see https://lwn.net/Articles/582648/) @rtiangha should know this.

[tabbyrobin]

Related: #716

[rtiangha]

The option changed in kernel 4.9 to CONFIG_SUSPEND_SKIP_SYNC, which is disabled by default. The option's description is such:

 Skip the kernel sys_sync() before freezing user processes.               
 Some systems prefer not to pay this cost on every invocation            
 of suspend, or they are content with invoking sync() from               
 user-space before invoking suspend.  Say Y if that's your case. 

The thing is, from what I can tell, simply enabling it isn't enough to encrypt the disk before suspend; the suspend scripts in userland would need to be modified as well to manually sync to disk and then lock it before suspending. And maybe modified to unlock it when it's brought back up (if it isn't set to do that already).

I could be wrong, though, but if that's the case, I don't think simply enabling the kernel option is enough, and I'd be hesitant to do so until there's something on the Qubes OS end that explicitly syncs to disk before suspending, since enabling the kernel option would mean the kernel would no longer automatically do it itself (and if userland changes do need to be made, then testing to ensure that the disk can be properly unlocked too).

[ptitdoc]

Quoting the cryptsetup man-page:

WARNING: never try to suspend device where is the cryptsetup binary itself.

Apparently, the project ubuntu-luks-suspend (https://github.com/jonasmalacofilho/ubuntu-luks-suspend) attempt to implement it by changing "to a chroot outside of the encrypted root fs"

If one want to protect the disk confidentiality integrity of the root partition (dom0), chrooting the root partition is probably a good solution. However if we just want to protect the user data (the AppVM private.img files), maybe using a separate partition for /var/lib/qubes and locking this partition is more easily feasible ?

This could be a good compromise as suspend protections are anyway not perfect (some user data including potentially end user keys/passwords will still be present in RAM and could be acquired).

[marmarek]

Having only part of the system encrypted is problematic, for example the part asking for the passphrase would be unencrypted. Or something loading dom0 system, which in turn load VMs (accessing that private.img). Some of this is the reason why AEM exists. But maybe that temporary chroot could be in RAM? Which still means the whole disk is encrypted (assuming booting from AEM device). Still some secrets are in RAM when system is suspended (VMs memory), but not disk key. Important thing is detection if someone have manipulated the suspended system. While disk encryption key wouldn't be there, someone could boot own system, copy the whole (encrypted) disk, then suspend it and wait until you provide the passphrase (and immediately sent it to the attacker). So, very similar problem as with evil maid attack. But as long as you keep an eye on your system, it should be safe, even if someone forcibly take the laptop away from you (but you know about it).

[jpouellet]

Note that there are various issues with suspend security enabling various vectors for compromise on resume, and that the more-paranoid user may wish to avoid suspend altogether. More information on this class of attacks can be found at:

• https://bromiumlabs.files.wordpress.com/2015/01/attacksonuefi_slides.pdf
• http://composter.com.ua/documents/Attacking_UEFI_Boot_Script.pdf
• http://blog.cr4.sh/2015/02/exploiting-uefi-boot-script-table.html

As far as I'm aware, this has not been meaningfully addressed by bios vendors.

Chipsec has modules to help evaluate vulnerability to some attack vectors:

• https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/uefi/s3bootscript.py
• https://github.com/chipsec/chipsec/blob/master/chipsec/modules/tools/uefi/s3script_modify.py

[airelemental]

I was able to get this to work thanks to https://groups.google.com/forum/#!topic/qubes-devel/NC61aNp-Phs

These instructions were tested on qubes-4.0, linux-4.19.15. It requires adding a ~125 line bash script to dom0, short enough to manually audit. The result is that sleeps (with lukssuspend) usually work, though you may have to sleep again if a service fails to freeze due to disk access presumably. (Try adding calls to the script to disable the service before suspend, and re-enable the service after.)

1. Download the self-contained cryptsleep script (written by Mrkva (http://dev.mrkva.eu) with qubes modifications by mkru): https://groups.google.com/d/msg/qubes-devel/NC61aNp-Phs/HNb-L3sdCwAJ

2. To use your current initramfs (which you presumably trust) instead of downloading their initramfs, make these modification to the cryptsleep script: a. Replace the INITRAMFS= line with INITRAMFS="/boot/initramfs-$(uname -r).img" b. where it copies /usr/bin/sync into the decompressed initramfs, also copy /sbin/cryptsetup and /usr/lib64/libpopt.so.0 to the appropriate directory. c. if you have microcode prepended to your initramfs, temporarily strip it off before extracting initramfs: Replace

   zcat "${INITRAMFS}" | cpio -i -d -H newc --no-absolute-filenames 1>/dev/null 2>&1

   with

   ( cpio -i -d -H newc --no-absolute-filenames 1>/dev/null 2>&1
   zcat | cpio -i -d -H newc --no-absolute-filenames 1>/dev/null 2>&1
   ) < "${INITRAMFS}"

3. Make systemd-suspend.service invoke cryptsleep: You can override the factory version without deleting it, by creating /etc/systemd/system/systemd-suspend.service with Requires=sleep.target, After=sleep.target, ExecStart=/path/to/cryptsleep.

4. Use qubes-builder to recompile dom0 kernel with CONFIG_SUSPEND_SKIP_SYNC=y. make linux-kernel-dom0 etc...

Edit: properly credit mkru Edit 2: updates

[AlexLJordan]

What is the status on this? What's y'alls opinion of airelemental s post? ?

[besendorf]

The sync_on_suspend kernel option has been implemented in linux-5.6. to support this. There was a talk about the project that submitted the patch and implemented a "Close lid to encrypt" for debian at fosdem. Talk: https://fosdem.org/2020/schedule/event/dip_close_lid_encrypt/ Kernel patch: https://lkml.org/lkml/2020/1/16/310 Repo of the project (cryptsetup fork): https://salsa.debian.org/mejo/cryptsetup-suspend

The thing left to do would be to port the fork to qubes and wait until qubes uses a kernel that supports sync_on_suspend (or backport it)

[xaki23]

wait until qubes uses a kernel that supports sync_on_suspend (or backport it)

not sure what that part means. kernel 5.6 is avail for qubes for the last few weeks already.

[besendorf]

Any news on this? Is this on the roadmap for any time soon?

[Trollfarmer]

Any news on this? This would be an awesome feature.