Wednesday 5 January 2011

Encrypted LVM for XEN domUs

The basic idea here is that I want encrypted partitions for my domUs (guests), but not for dom0. The reason for this is that I normally does not have physical access to the machines, so I will need to have the machine boot and start sshd without user interaction.

These notes are from a Debian Squeeze dom0/host, with a single 1TB drive installed. dom0 is not in the LVM. Note that these notes are not XEN nor Debian specific, this is just the solution I went with for running XEN guests in an encrypted LVM on my configuration. You should be able to do similar for pretty much any Linux Distro, with or without XEN.

Install packages
aptitude install lvm2 cryptsetup

Create partition for LVM volume group (vg)

I use cfdisk for this (curses-interface). Basically you need to choose the free space to use, make it a primary parition. I chose tyoe 8E (Linux LVM) for the drive, but I am not sure if this is necessary. Remember to select write in cfdisk before exiting.

For me the parition table looks like this at this point:
Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        3648    29295616   83  Linux
/dev/sda2            3648        3891     1951745    5  Extended
/dev/sda3            3891      121601   945510624+  8e  Linux LVM
/dev/sda5            3648        3891     1951744   82  Linux swap

At this point I had to reboot to actually be able to do anything with sda3. This might be due to some XEN magic I don't understand yet. If I understand correctly dom0 has access to most hardware, but must be given so through the XEN hypervisor.


Create and unlock an encrypted container

We need to create something called an encrypted container for the LVM, which basically is what makes encryption happen for the LVM

Create encrypted container
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sda3

You will be asked to give a password, which needs to be remembered/written down. This will be required each time you want to unlock the encrypted LVM (after every boot). Now this container will be locked by default so we will have to open it (you will be asked for the passord):

Unlock encrypted container
cryptsetup luksOpen /dev/sda3 crypt

Set up LVM

With the encrypted container we can actually set up/use the LVM

Create a Physical Group
root@moonlight:/home/zerqent# pvcreate /dev/mapper/crypt
  Physical volume "/dev/mapper/crypt" successfully created
Create a Volume Group (vg)
root@moonlight:/home/zerqent# vgcreate vg /dev/mapper/crypt
  Volume group "vg" successfully created

Ready for action

You are now ready to create Logical Volumes (lv)s. Remember that you will have to unlock the lvm after each boot, or if you lock it.

Unlock LVM after boot
/sbin/cryptsetup luksOpen /dev/sda3 crypt
vgscan --mknodes
vgchange -ay

Application with XEN

Performance wise the net tells me that XEN guests running on LVM as opposed to images (files) is better. With this setup you will have to unlock the LVM exactly once if dom0 needs to reboot. Alternatives for this setup could be encrypted Volume Groups, encrypted-LVM-in-LVM (e.g. during install of guest you create an encrypted LVM which actually already resides in the LVM exposed by the XEN hypervisor).

Security considerations

What security gain you get from this is somewhat questionable. If Dom0 is compromised and the LVM is unlocked you get none. Also a running system with the LVM unlocked will have to store the encryption key somwhere, so this could be compromised. However if someone should steal your computer I deem it unlikely that they will recover anything from the encrypted LVM. These thought are of course based on the understanding that you do not generate, nor store the key to unlock your encrypted drives on the same computer as the LVM resides.

No comments:

Post a Comment