Swap device encryption on all VMs

[DemiMarie]

Qubes OS version:

R4.0

Affected component(s):

dom0 storage management system

---

Steps to reproduce the behavior:

Discover that swap devices are unencrypted (except by FDE).

Expected behavior:

Swap devices (both dom0 and domU) are encrypted with a random, unique key. This key is not stored anywhere on disk, and thus dissappears on system shutdown.

Actual behavior:

No such encryption

General notes:

This ensures that paging cannot leak sensitive data to disk, where it could persist for far too long.

---

Related issues:

[unman]

Is this not a duplicate of #1293?

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[andrewdavidwong]

Reopening and unmarking as a duplicate at the request of @brendanhoar in https://github.com/QubesOS/qubes-issues/issues/1293#issuecomment-458124101:

4408, closed as duplicate of this current issue, is actually a request for all (known) swap files to be encrypted in Qubes by policy, and not a request for user-managed per-VM encryption. That is, it is really an anti-forensics focused issue.

[DemiMarie]

I have implemented this myself as a Salt state. It works by using dm-crypt to encrypt each qube’s swap device with a key generated in that qube. I would expect it to need further auditing before it is made the default in QubesOS. That said, it works well on my system, other than #5028.

[DemiMarie]

I believe that since the attack surface of dm-crypt is negligible, doing the encryption in dom0 would be preferred. I have not implemented that, due to the additional complexity that results.

[brendanhoar]

It's a shame that lvm2/device-mapper doesn't already include the ability to create non-persistent snapshots utilizing a mapping target that is a combination of the snapshot mapping target and the crypt mapping target (with an in-RAM key). The snapshot API already has a persistent (P) vs. non-persistent (N) flag capability controlling whether the snapshot survives reboots. A "really-non-persistent" (RNP) flag (and the significant code changes to make it happen) would make this easier to control from dom0 VM config. :)

Rhetorical question: I wonder if there would be applications for lvm2/device-mapper supporting encrypted snapshots outside of this Qubes use case (controlling disposable VM swap crypt from dom0) or for other Qubes use cases (password/encrypted protection of sub-trees of Qubes VMs located on a single thinly provisioned logical volume). Maybe I should ping the maintainers...

Brendan

[DemiMarie]

This will be solved by QubesOS/qubes-core-admin#396, which encrypts all volatile volumes by default. This includes the swap partition, as well as the CoW root volume if the root volume is set to read-only.

[DemiMarie]

Fixed by https://github.com/QubesOS/qubes-core-admin/pull/396 and its successors.