On 10/27/2016 01:31 PM, 7v5w7go9ub0o wrote:
>
>
> 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)?
tmpfs is swappable by default. You would have to swapoff.
> 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.)
I do not know what the status is on keeping the whole DispVM in RAM, but
there is an issue filed on the matter. Check the qubes-issues Github repo.
>
> p.s. Thank You for your helpful postings here!!
>
>
--
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/b01247de-7999-98ef-90f0-e0bb3cffb4cb%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.
