On 10/26/2016 04:46 PM, maritnez wrote: > you have a file that contains sensitive banking data and would like to delete > it without leaving any traces on your system. > > you can 'move it to trash' > which moves it to the trash > > you can then press the delete button in your trash container but > is this really securely deleting the file without any chance of recovering it? > > > how to delete files without leaving ANY trace from it? >
Here is what happens when you do that in a VM, assuming the data is stored in /home or /rw: 1. VM file moves to trash. 2. you empty the trash in the VM. 3. In 5 seconds, the VM kernel's ext4 file system commits the metadata change to /dev/xvdb, and discards the data blocks that were occupied by the file. 4. The discard makes its way to dom0's /var/lib/qubes/appvms/vm/private.img by way of the loopback device that was connected to the VM in representation of the private.img file. 5. Since loopback devices honor discard, and since loopback devices mapping files issue PUNCH_HOLE or zero out the relevant data on the file, that means the discard operations make their way into private.img as either blocks zeroed out or PUNCH_HOLE operations. 6. The dom0 file system hosting that private.img file can do any number of things about these incoming operations: 6.1. If ext4: after 5 seconds, the discard operation makes its way to the underlying block device; this may be 100% ineffectual in rotational devices that do not support discard, and may also be 100% ineffectual in the case of SSDs as they may decide to forego deleting the data and just add those disk regions to a fresh pool of writable flash (while keeping the "zeroed" data hidden from you. but certainly not from governments) 6.2. If ext4 on top of LVM: ask someone else, as I'll put it bluntly: I do not know what that shit does, and I do not know if anyone knows. 6.3. If ZFS or btrfs: the file system code will do copy on write, which means the blocks will still be available in some other region of the disk, until they get overwritten by new writes. Worse still, if the data you just tried to zero out in the VM actually happens to be in a file system snapshot of dom0, then by definition it will not ever get deleted, until you kill the snapshot and zero out all storage on the devices. It's more complex than that, though. First rule of thumb: IF you wrote X to disk, THEN be sure X is going to be there. Second rule of thumb: IF you read data chunk X with a program at some point, THEN it's likely that X is going to be on disk too, because of swap (read -> memory -> swapout -> disk). The way to get around these rules of thumb is (a) make sure that data always hits the disk encrypted (b) make sure to never ever let any adversary read from that disk while unencrypted, or obtain the key to that disk. The takeaway: deleting data is REAL HARD. You better have a good encryption password. The honest, cheap-to-execute answer to your question is: get a blowtorch and torch the individual data-bearing parts of the drive, until each part changes color, and then some. Don't breathe the magic smoke coming out of these parts — it may kill you. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2f9d9593-ec64-e931-6946-4078ec986115%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.