On 10/27/2016 12:14 PM, Manuel Amador (Rudd-O) wrote:
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.
(Heh....... "magic smoke", eh!?)
(Newbie question:) Is there a possibility of using "mlock" to block
swap; working entirely in ram - de-crypting the imported subject file
using "tmpfs" interim files, then exporting the updated, encrypted
subject file back to vault (or out the door)? I'd guess this would leave
you vulnerable only to someone hands-on dumping your memory? I'd presume
doing all of this in a DispVM would preclude some "relic" remaining in a
Domain. (One wouldn't want any (encrypted) relics in case of a
rubber-hose interrogation and demand for passwords.)
p.s. Thank You for your helpful postings here!!
--
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/f5303c85-6554-68ce-2901-2b8b69ffcd1b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
