Bug 1381502

I'll just note if you want to securely delete a file, you should
use the virt-sysprep --scrub option.

For this bug, we just run fstrim, so if the file is still there
it's because either the kernel or qemu is not removing it.
Therefore reassigning to the kernel.

Hi Piotr,

Can you please clarify whether you can still see the actual file? Or do you only see the known content of the file in the raw filesystem image?

Thanks,
Harshula

Hi Harshula,

The deleted files are removed and don't appear in operating system.
Their content however is still on virtual hard disk image file and therefore is recoverable.

I'm preparing a process to automatically generate hardened cloud images and one of the tasks is to completely erase sensitive data from image to prevent end users "trash diving" and trying to recover something from raw sectors. 

Thanks, Piotr Muchowski

Hi Piotr,

1) Thanks for the clarification confirming that the deleted files are NOT still there.

2) Did you try using "virt-sysprep --scrub"? Did that ensure that the known content of the file is NOT present in the raw filesystem image?

Thanks,
Harshula

Hi Harshula,

I have tested this today on CentOS 7 cloud version, and not on Fedora yet.
Anyway it seems this is not kernel or qemu issue.

I tested with scrub option and yes, the scrub removes the content as expected. But because there is no global virt-sysprep's "scrubmode=always-on" option, the "--scrub" can be used only with files provided by command line, the other virt-sysprep cleanup modules do ordinary file deletions and files therefore are recoverable. 

Virt-sparsify could remediate here but it doesn't recognize areas occupied by deleted files as unused and doesn't trim it. Perhaps it rather works on disk sectors instead specific bytes and maybe the affected sector cannot be trimmed as it contains other data as well.

virt-sysprep man page says i can use virt-sparsify to securely remove data. I thought it works reliably and discovered this issue only by accident.

Regards, Piotr

virt-sysprep man page actually says:

       Although virt-sysprep removes some sensitive information from the
       guest, it does not pretend to remove all of it.  You should examine the
       "OPERATIONS" above and the guest afterwards.

       Sensitive files are simply removed.  The data they contained may still
       exist on the disk, easily recovered with a hex editor or undelete tool.
       The --scrub option can be used to scrub files instead of just deleting
       them.  virt-sparsify(1) is another way to remove this content.  See
       also the scrub(1) command to get rid of deleted content in directory
       entries and inodes.

virt-sysprep --inplace simply performs an fstrim operation, so
it relies on the kernel and qemu doing the right thing for fstrim.

fstrim has its own limitations of course.  It only operates on blocks
of a particular size (blocksize depends on many factors but can be
read from /sys/block/*/queue/discard_*), and it is possible that file
boundaries might not align with block boundaries.

You can also look at the guestfish 'scrub-device' command, which is
also an interface to the scrub(1) command, but should write patterns
all over the free space in the filesystem.  It'll probably be quite slow.

OK, I will do research on this topic later, thanks for the advices.
It seems that such advanced image sanitization needs just more steps than ordinary cloud image preparation (at the cost of increased execution time).

Gday Poitr,

Thanks for the report, at this time we don't consider this a security issue.  If you have any further information please don't hesitate to add a comment and re-open this bug and we can continue this conversation.

Thanks,

Wade Mealing
Red Hat Product Security