That being said...
In 4.0 (updated) qubes now calls blkdiscard on volumes being removed before invoking lvremove. If you happen to use a SED SSD and you have manually enabled discards through all layers to the physical drive, then, depending on the manufacturer implementation, the data from a shutdown disposable VM might not be recoverable even with your disk password.
No guarantee but I recommend enabling discards all the way down.
After some forensics experiments, I put together a rough-at-the-edges bash script that does a rather good job of ensuring the volumes are not recoverable.
It creates an over-provisioned lvm volume In the current pool, overlays a new randomly keyed luks volume on top, makes that into an lvm pv, layers lvm vg and finally an lvm thin pool on top.
Adds that new thin pool to qvm-pools, copies templates and VMs there, temporarily modifies the global default pool setting (needed to be sure *all* volumes related to the VMs were in the ephemeral pool) and starts up some sessions.
I need to make it a bit more flexible but it served my need.
Once all started VMs are shut down, the script unwinds all the storage layers.
Since the luks layer was random keyed, that data is gone once unmounted.
Been meaning to clean it up and share at some point.
> Disposable VMs were not developed with anti-forensics in mind (e.g. no protection in jurisdictions where you can be forced to hand over your drive password
Never thought about it, but that makes sense. I can see how it would be
easy to confuse "non-persistence of malware" aspect and the
"non-persistence (non-remenance) of data" aspect, though.
But then... What does the checkbox mean, "Keep dispVM in memory", under
global settings (R3.2, at least)? Screenshot attached.
I sort of like the idea mentioned in bug #904, about doing the crypto
inside the dispVM itself, so that 1) the key is scrubbed by Xen when the
dispVM is shut down, and 2) data is non-recoverable instantly so you
don't have to wait until all dispVMs have been shut down for example.
Incidentally this approach actually offers a lot of improvement in
scenarios where the machine is seized while it's on and unlocked, too,
but that's another topic.
Just bouncing around some ideas. Seems like it might be possible to do
something like that, and perhaps simpler than the ephemeral pool
approach, depending on your situation. Thoughts?
On 2019-12-15 22:04, brend...@gmail.com wrote:
My suggestion is, rather than the time consuming wiping of bits after
the fact would be to instead create an encrypted volume/partiton/pool
when launching a DispVM, and upon shutting it down you simply throw away
the key to that temporary volume. Without the key any data on that
encrypted volume would be unrecoverable, so then all you really need to
wipe is just the memory space that stored the runtime key's working
memory. If the key is generated before the volume is created then the
key would be only available to dom0 where the key's working memory space
can be managed properly and Qubes would be able to support any number of
guest OS's as a DispVM.
If the volume were intentionally stored on an Opal 2.0 SSD device you
could then use the built in SSD hardware capabilities of the 'encrypted
locking range' (up to four are possible if I remember correctly) for the
temporary workspace and when you destroy/reset the MEK (key) this will
instantly flip all the bits in the underlying hardware of that disk
region and make that range completely unrecoverable.
This script shows the approach I take for an ephemerally keyed lvm pool: