QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
543 stars 48 forks source link

qvm-clone: add `--move` and `--shred` #3717

Open rootkovska opened 6 years ago

rootkovska commented 6 years ago

This is to facilitate (reasonably safe) migration of qubes from one pool to another (e.g. located on a USB disk). When using together with --shred the tool should also shred (dd if=/dev/zero) the corresponding volumes, and at least display info about any volumes which it does not move to the new pool (e.g. root and volatile).

marmarek commented 6 years ago

IMO it shouldn't be part of qvm-clone tool. Do you mean moving volumes between pools without creating doing internally qvm-clone + qvm-remove - in other words - keeping VM name? If so, IMO it should be part of qvm-volume tool - add migrate action or such.

Also, keep in mind that this feature (dd /dev/zero) may be misleading - if you used the qube in the old pool for some time, there are almost certainly some data blocks no longer connected to its volume, scattered over the disk, but still having that data (until reused form something else). If you want to move a single RSA private key (i.e. something that can easily fit into a single block) away from the source pool completely, you might be disappointed with this method.

tasket commented 6 years ago

One method Mac OS X used to erase formerly associated blocks was to offer options to "erase unused space" in Disk Utility; this could actually work on (simple, flash-less) spinning HDDs.

This might be emulated in Qubes LVM by renaming the target volume as 'temp' and then extending the vsize to at least the pool size and filling it up (in a special mode where most related VMs are stopped). Finally, remove the temp volume and resume normal operation.


On SSDs its more complicated because of wear-leveling, and issuing TRIM commands may or may not wipe block contents (or not immediately). If you don't completely trust the drive firmware then the only way to ensure effective erasure is to have the volume encrypted separately in the first place; then throw away the key. Such volumes could be flagged as "shred-able" (a runtime property that depends on the volume having its own separate encryption key and/or residing on a simple HDD).

PowerPress commented 6 years ago

Any plans to implement this to wipe/shred the data or have the volume encrypted separately in the first place; then throw away the key? Would be a great option to have Qubes have a clickable option for this in each VM, in my opinion, so that traces of something are not left behind once a VM is disposed of.

andrewdavidwong commented 6 years ago

Any plans to implement this to wipe/shred the data or have the volume encrypted separately in the first place; then throw away the key? Would be a great option to have Qubes have a clickable option for this in each VM, in my opinion, so that traces of something are not left behind once a VM is disposed of.

This sounds more like #1293.