1

Here is a tricky one: Can you securely delete a file from a VM?

I'm sure the answer is dependent on a million different variables, and I'm sure the answer is something like "not really" but I want to hear what the experts think and why.

If secure delete is not possible via conventional methods like shred, is it possible via unconventional methods?

If secure delete is simply not possible (or beyond the capability to assert) then what is the implication for "the cloud"? Is "the cloud" simply not viable for security? Or does it mean we must use full disk encryption at all times in "the cloud"?

  • You need to clarify whether you are asking if its possible to securely delete a file WITHIN a virtual machine or whether you can securely delete a file from another device that is connected to the virtual machine. – CPagan Jan 28 '15 at 23:33
  • 1
    I think he means the former. Certainly it must be possible. For example, the extreme measure of wiping the entire HOST hard drive would certainly securely delete the file from the guest (along with the entire guest and everything else). There is probably a less extreme alternative too. – hft Jan 29 '15 at 4:28
  • Could you not use a live CD for your virtual machine? That way it never installs to the hard drive and nothing is saved – TimC Jan 29 '15 at 7:51
  • I am asking about securely deleting from within the virtual machine, I have no access or information about the host or its specs. (I'm paying a provider for the VM). Ideally I'm looking for a secure delete without needing the host to do it, if that is possible. To me it doesn't sound feasible with the limited information/access I have, but I was hoping someone on here would have a clever solution. (I don't do any remote backups or automatic VM imaging -- it is not clear if the host does any of this behind the scenes) – Radmilla Mustafa Jan 29 '15 at 18:43
4

No, absolutely not.

A virtual machine lacks the necessary knowledge and control over the underlying storage infrastructure to ensure secure deletion of data.

For any number of reasons, writes may be redirected to new blocks and thus leaving the old data intact on physical storage. This is a typical behavior for SSD devices due to wear leveling, for storage arrays and filers for reasons related to error correction and efficiency, and by any sort of snapshot functionality to support backup, cloning or data retention.

There may be exceptions in certain configurations where the hypervisor is able to facilitate deletion (by means such as an API that can be called from the guest), or where the VM has enough of a direct relation to physical storage (By means such as I/O paravirtualization or attaching an iSCSI device directly to the guest), but in general you should not depend upon any virtual machine to overwrite specific physical blocks.

Particularly in the case of a virtual machine in the cloud (Infrastructure as a Service aka Virtual Private Server) you can not expect to exert any influence on physical storage. On a poorly implemented service it's conceivable that blocks of data can leak to neighbouring virtual machines.

Sensitive data should be protected with encryption at rest or perhaps stored on a trusted storage service that can provide the required level of security.

Much of this even applies to physical servers, you need to know the specifics of the storage components to ensure secure deletion - eg. release snapshots, recondition cells, destroy redundant block copies, rewrite parity information, clear out journals and transaction logs or commit write-back cache to disk - all depending on type of storage.

0

Im jumping on the "not possible" bandwagon here,

Since we are not aware of the backup policy of said cloud provider (nor are we aware of their level of employee access)

it can be quite possible that a copy of your VM's drive is floating around somewhere.

In addition to this I have had a few different hosting providers where I have required tech support, and found that they have direct root access to my vm (even though I have changed all passwords and revoked all SSH keys provided. ) so I am guessing its via some additional method (most likely something injected into PAM or the kernel which they provide.)

I have not cared that much because I have not ever had anything too sensitive stored but if you do then I would recommend locking down physical access to the machine.

  • In Cloud systems, your host have hypervisor privilege, which is even higher than the guest OS's root privilege. For one, the hypervisor can lie to the guest about disk deletion, they can make a copy of the guest's disk that's undetectable by the guest, or modify the guest's files to add an extra privileged user or to install an undetectable rootkit. Nothing you do in the guest can prevent them from doing these. – Lie Ryan Jul 13 '16 at 16:26
0

Yes. The virtual-machine (VM) hard-drive disk file is effectively a virtual disk file that holds a master boot record (MBR), partitions and file systems on the virtual disks are equal to an physical hard-drive.

A data storage device, like a physical hard drive, is only a raw device that stores data from zero to end, no format or anything. The format of the data is decided by the application (the operating system) storing data on the disk.

The same thing can be applied to an individual file. Thus, you can store a hard drive inside a hard drive inside a hard drive and so on (while the last one is the physical one).

The conclusion is, that you can securely delete data from a VM in the exact same way as you would do on a real system. You need to take in consideration which file system the guest operating system uses, since it might use journals and such, and sensitive data can leak that way if you do not wipe the data correctly.

Some VMs might also not flush changes to the virtual hard drive to real disk before shutdown, so if you want to do a secure wipe, you might need to wipe a 1 pass, then shutdown and start VM, wipe 1 pass again, and then shutdown and start VM, and do the final wipe pass.

Also take into consideration that the host OS might save journals and sensitive data of the actual VM virtual disk file. To solve this, I would suggest COPYING the completed VM disk file (eg where the sensitive file is wiped) to a new location, then wipe the old VM disk file, including any metadata like journals and such, and then copy the new file (the copy) back to its original location. Such a system could be coded with a batch script that you use every time you have securely wiped a file from a VM.

Note that if you do NOT have access to the host OS on the VM in question, then you might not be able to securely wipe files on VM at all. Then I would suggest encrypting the VM and when its time to say goodbye to your VM, you simply destroy the encryption key.

  • If it comes down to destroying the entire VM or virtual storage device, some VPS vendors/IaaS providers give the option of scrubbing the storage and any backups. – Roy Mar 8 '15 at 0:55
  • 3
    The conclusion does not make sense to me. You can not assume that any specific physical blocks will be affected by operations issued within the VM. The simplest example to the contrary might be VM or storage snapshots. If the hypervisor, host OS, host file system or some part of the storage subsystem maintains a snapshot that includes the virtual disk file, you can scrub the virtual disk device all you want without ever touching the relevant areas of the physical storage device. – Roy Mar 8 '15 at 1:16
  • In this answer, I make the presumption that the host OS is accessible and that the administrator is in control of backup routines. As I said in the last paragraph of the answer, if the administrator of the virtual machine does not have access to the host OS, it might not be possible to wipe at all. – sebastian nielsen Jul 22 '16 at 0:11
  • Ah, I can see how that fits. However, if you have privileged access to the underlying infrastructure, I feel the question itself is robbed of all relevancy. – Roy Jul 22 '16 at 1:01
  • @Roy : The question is if you can securely delete from inside a VM. A owner of a VM might want to be able to securely delete from inside the VM even if he is able to wipe from the host OS, for example if the owner of the VM wants to securely delete just a single file, or be able to schedule the wiping of a certain file. Under certain circumstances, this is possible from inside the VM, thus the OP can make sure these circumstances are set. Compare the VM disk file with a truecrypt container, but unencrypted. If you wipe something inside the TC container, it will aswell be wiped in the disk file – sebastian nielsen Jul 22 '16 at 1:07
0

Guest operating system usually has no access to machine's hardware (You can create a virtual machine that uses a physicall hard drive, but it's not the most common) so you can't rely on guest machine overwriting the corresponding blocks

I think the best way to achieve what you want is just using a full encrypted hard drive in the guest machine and don't need to worry about securely deleting files

  • ...which comes with exactly the same issues as full-disk encryption on physical servers, except now you also can't use a TPM or HSM to hold the key that allows access to the encrypted volume but still need the system inside the VM to boot likely with no external input. – a CVn Jul 13 '16 at 17:54
  • @MichaelKjörling : Somewhat depending on how and where you do the encryption you may still use a software vault or a hardware module to safeguard the secrets. The external key storage could be accessed when unlocking LUKS devices or when enabling access to SAN, NAS or possibly even local storage, that offer some sort of properly implemented storage-provided encryption. Even without key management, local data encryption could offer protection against accidental access to deleted data, as it is unlikely that encrypted blocks will happen to be linked to the proper cipher and key. – Roy Jul 19 '16 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.