Host vs Guest Encrypted LVM

When using VMs for privacy, is it better to encrypt host machines or VMs? I've primarily used VirtualBox on Ubuntu, and it's been most convenient (and seemingly secure) to just use encrypted LVM on hosts. While VMs are running, hosts can see everything, and using encrypted LVM on VMs wouldn't prevent that. And while hosts are powered off, everything is securely encrypted, including any data that hosts have cached from VMs.

But there's a vulnerability: while hosts are powered on, all virtual disks are insecure, with just user password "protection". The vulnerability is more serious when there many VMs, and when data on some is far more sensitive than data on others.

Now I'm facing the opposite problem. I'm switching to ESXi on hardware retired from business use. As far as I can tell, ESXi doesn't include storage encryption, and neither does the hardware that I'm using. And so I've been playing with encrypted LVM on VMs. Performance is impressive, especially when I put boot partitions on low-latency LUNs. However, anything that's cached from VMs to the host is insecure, even after the host is powered down.

Leaving that issue aside for now, it seems to me that encrypted LVM on VMs is no less secure than encrypted LVM on real hardware. Both are insecure when decrypted, and secure otherwise. After all, images of real disks and virtual disks are readily convertible, so the distinction is largely irrelevant. It is, I suppose, harder to image real disks than to copy virtual disks, but not very much.

Does that make sense?

In exploring this, I've had to learn more about managing disk images. It's quite amazing. Flat VMDK disks (which ESXi calls "thick") can be manipulated just like ISO images. VDI and "thin" VMDK disks must first be converted to flat VMDK format. The drill follows. Do this in a VM, in case something goes horribly wrong.

sudo losetup /dev/loop0 ~/my-crypto-LVM-group-flat.vmdk
# use "sudo losetup -d /dev/loop0" to delete loop when done
sudo fdisk -l /dev/loop0
# to get partition table offset
sudo losetup -o [offset in bytes] /dev/loop1 /dev/loop0
# use "sudo losetup -d /dev/loop1" to delete loop when done
sudo cryptsetup -v luksOpen /dev/loop1 foo
# supply passphrase when prompted
# use "sudo cryptsetup -v luksClose foo" to close when done
sudo pvs
# see both host LVM group and "my-crypto-LVM-group"
# can also run "sudo lvdisplay" for details about logical volumes
sudo vgchange -ay cryptolvg
# to make logical volume(s) in "my-crypto-LVM-group" active (e.g., root)
# use "sudo vgchange -an my-crypto-LVM-group" to deactivate
sudo mount /dev/cryptolvg/root /mnt/bar
# which is the point of it all

 

I would say it depends on what the normal running state of the host is. If it is your desktop in the basement, or a server that is always on, then encrypting the host is relatively useless (unless you never leave the house and can be sure you can power it down during a dynamic entry )

If it's a laptop, then encrypting the host seems like a good idea.

I have no idea on the performance hit that would occur if you did both...I have yet to venture into VM land.

I hope someday, that Ubuntu (or Linux in general) will stop advertising with the LUKS header. How hard could it be to come up with plausible deniability on Linux?

PD

 

Indeed. This server is a ponderous beast, with SAS-attached storage. Although my UPS has a "panic button" circuit, just killing power might corrupt stuff. The HBAs do have battery backup, but that could cut both ways.

Still, without host encryption, ESXi may leave sensitive stuff swapped to disk. Maybe I can secure that somehow.

Yes, that's clear.

There's no better time than now

Playing with the LUKS header is very dangerous