Use Case

I have an Ubuntu server machine wrapped in a VM (vmdk file) that contains web application. I want to send this VM to someone and prevent him from accessing to the internal file system of the VM - I don't want to let him extract the machine's file system from the vmdk file.

The user can just start the machine or power it off (when the machine starts - it loads the application back-end services automatically).


I though about using a hard drive encryption (Full Disk Encryption using LUKS or other solutions like VeraCrypt) but my main concern is how it will be used in a server-based environment.

I don't want to let the user to enter any decryption keys or something like that - I saw that there are solutions for decrypting the file system automatically at start like here and here and it seems like i need to store the decryption keys inside the vm.

Is there a way to decrypt the machine by maybe using a remote user login? (I'm less concerned from more complex issues like side channel attacks or Hot VM Cloning). Or any other solution that can meet the use case?


After @vidarlo answer I decided to go with the FDE solution understanding the trade-off.

Below the configuration instructions I used (Assume that the /boot resides on the /dev/sda1 unencrypted partition and the encrypted one is on the /dev/sdaX partition).

Create a new random password and store it in the luks key store:

sudo dd if=/dev/urandom of=/boot/keyfile bs=1024 count=4
sudo chmod 0400 /boot/keyfile
sudo cryptsetup luksAddKey /dev/sdaX /boot/keyfile

Get the UUID of the /dev/sda1 partition by running:

sudo ls -l /dev/disk/by-uuid/

Update the /etc/crypttab file with this content:

sdaX_crypt UUID=<UUID_OF_SDAX> /dev/disk/by-uuid/<UUID_OF_SDA1>:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev

Update the initramfs

sudo update-initramfs -u


sudo reboot

You can set up a solution with unencrypted /boot, and a LUKS key file:

sudo cryptsetup luksAddKey /dev/sdx1 /boot/random_data_keyfile1

Modify /etc/crypttab to suit:

sda5_crypt UUID=DEVICE_UUID /dev/disk/by-uuid/devicewithkey:/random_data_keyfile1 luks,keyscript=/lib/cryptsetup/scripts/passdev

This is not foolproof. Any remotely skilled attacker will find the unencrypted /boot, and the keyfile. You can obscure it to make it harder, but ultimately your problem is unsolvable.

You want the person to be able to execute the virtual machine, yet unable to access it. Execution requires access. Worst case? Pause the VM, and examine memory of the VM. Anyone that has control over the hypervisor has total control over the VM, almost no matter what you do.

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.