New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rootkovska opened this Issue Mar 19, 2018 · 4 comments

Comments

Projects
None yet
6 participants
@rootkovska
Member

rootkovska commented Mar 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 19, 2018

Member

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.

Member

marmarek commented Mar 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Mar 28, 2018

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

tasket commented Mar 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@PowerPress

PowerPress Jun 28, 2018

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.

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

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Jun 29, 2018

Member

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.

Member

andrewdavidwong commented Jun 29, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment