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.

[schnurentwickler]

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

[sptankard]

Related: #716

[sptankard]

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

[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).

[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).

[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

[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