How To Migrate to a full encrypted LVM system
Posted by gpall on Mon 28 Jan 2008 at 15:07
The point of this how-to is to describe the way to migrate to a full-encrypted LVM system (rootfs + data) (only the boot partition obviously stays unencrypted), either coming from an LVM system, either from a simple ext3 system. All you need is some kind of external storage.
It should be here noted that since the operations described below are not very trivial, this procedure should only be followed by people somewhat experienced.
PART I - Installing neccessary software and saving the current system
There are two ways to implement the LVM full encrypted system:a) the debian way (TM), which has the LVM on an encrypted virtual device (cryptsetup)
b) the other way, which first makes an LVM on your physical devices, and then encrypts the logical volumes
I preferred the debian way of course, although I don't find any specific reason for that.
My initial setup had /dev/hda1 as NTFS Windows and the rest, you don't care, because we won't be keeping any of the partition/LVM structure.
Before you attempt any of the following, do yourself a favour and take a full disk backup using CloneZilla, to some external storage. This way, when you screw up, you won't lose your smile.
To begin with, install 'cryptsetup'. Also, your kernel should include a initrd image to boot with. If not, install package initramfs-tools. Then create the following file inside /etc/initramfs-tools/conf.d
filename: cryptroot
contents:
target=lukspace,source=/dev/hda3,key=none,lvm=vg-root
After, that run a:
# update-initramfs -u
This builds an initrd image which knows where to look for the encrypted partition that we will make.
--EDIT: After filing a bug report about this file 'cryptroot', the developers informed me that this file is not needed, so I deleted it (after having completed the whole migration process). Everything seems to be working fine.
Second, and this is mandatory, take a tar of your system to this external storage using:
# tar cSjf /my/external/storage/sysbackup.tar.bz2 /bin/ /boot/ /etc/ /home/ /lib/ /opt/ /root/ /sbin/ /selinux/ /srv/ /usr/ /var/
(if you prefer speed, you can omit 'j' from tar (and .bz2 of course))
This will save all necessary permissions, files, ownerships etc etc. As you can see I have omitted the following directories: /dev/, /media, /mnt, /proc, /sys, /tmp. These will have to be recreated on the final system (except /media).
My suggestion is not to use the system while doing the backup, i.e. no X-window sessions, and no other consoles other than root's.
Now, time to get all your data to the external storage. Let's say they reside on a partition mounted on /media/abyss. Of course, /media also has cdrom and other useful things.
So:
# tar cSjf /my/external/storage/databackup.tar.bz2 /media/cdrom /media/whatever /media/... everything EXCEPT the mountpoint of your external storage!!!
OK, so at this point you can take a breath. Your system, if you have not done something unclever, is secured against any kind of misconfiguration and child-eating experiments.
PART II - Reformating disk and creating the encrypted LVM structures
Remember again that if at some point, things go bad, you can always use clonezilla to restore your old system.
Now that your system is secured let's play around!
I use the clonezilla CD for most of the jobs as live CD.
So, boot Clonezilla, and give it network. Then enter a console prompt (sudo su) and...
# aptitude update && aptitude dist-upgrade
Before that, you may need something like that:
# ifconfig eth0 up
# dhclient eth0
After sometime your live system will have all the latest & greatest debian software so time to install a couple of tools:
# aptitude install cryptsetup joe
Joe is my favourite editor, so for the rest of the how-to we'll pretend it is yours too.
First, let's destroy your disk!
# cfdisk /dev/hda
and delete all partitions except your /dev/hda1 (NTFS).
Then create a primary partition that will be used for booting: /dev/hda2, with a size of 200 MB.
Then create another primary partition with the rest of the free space (/dev/hda3). This will be your future rootfs and data home.
Then write the partition table to the disk and exit.
This whole fuss just rendered your operating system inoperable and your data a bit crappy. But don't ya worry, we got everything on tar!
We want now to utterly destroy everything on the disk and fill it with random little bits, while at the same time checking for badblocks. Here we go:# badblocks -s -w -t random -v /dev/hda2
# badblocks -s -w -t random -v /dev/hda3
these two commands will utterly destroy all data on your disk. They will need some time though to do that, so be patient.
After that, let's first give a filesystem to the boot partition. Easy:
# mkfs.ext3 /dev/hda2
Then we will use cryptsetup to make the big partition a dm-crypt device. This is also as easy as stealing from children.
# cryptsetup -y -s 256 -c aes-cbc-essiv:sha256 luksFormat /dev/hda3
I may not have the options in the correct order but this will get you going. Note: Give a good passphrase that you will also remember. You can change this passphrase afterwards, and you also can have multiple passphrases!
Now, time to use this initialized space:
# cryptsetup luksOpen /dev/hda3 lukspace
This will ask you for the previous passphrase. After that, you will see a /dev/mapper/lukspace appearing. This can be now regarded as a device, ready to accept any kind of data. You can format it with ext3, or you can build an LVM on it, which is what we will now do.
So, let's create the LVM.
# pvcreate /dev/mapper/lukspace
# vgcreate vg /dev/mapper/lukspace
# lvcreate -L10G -nroot vg
# lvcreate -l 100%FREE -nmyspace vg
So, we now created the LVM logical volume /dev/vg/root which will host the root filesystem and /dev/vg/myspace which will hold our data! That wasn't difficult, was it?
And now something trivial: format the partitions we've just made...
# mkfs.ext3 /dev/vg/root
# mkfs.ext3 /dev/vg/myspace
PART III - Restoring system files and booting the new system
After we've created the space for our root filesystem, time to untar our system to its new space.
First of all, we create a mountpoint, say /media/rootfs and we...
# mount /dev/vg/root /media/rootfs
and now...
# cd /media/rootfs
# tar xSjf /external_storage/sysbackup.tar.bz2
and wait for it to finish.
Next, create the directories which are needed but were not backuped:
# mkdir proc sys media dev tmp mnt
# chmod 1777 tmp
Now create elsewhere a bootfs mountpoint and mount our future boot partition:
#mkdir bootfs
# mount /dev/hda2 bootfs
Then move the boot files from rootfs/boot to this new bootfs place. So, now the /dev/hda2 boot partition has the necessary files to boot.
Pray, and reboot! Be prepared though! After grub has loaded, press 'e' for edit at the kernel option and set the correct root=... option so that the machine can boot!
Hopefully, LUKS will ask you for your passphrase and everything will go just fine!
After you enjoy a couple of minutes playing with your all encrypted system, edit /boot/grub/menu.lst to point to the correct root=... device, and run an update-grub.
Giorgos Pallas
PS. If you have come that far, you don't need me to tell you how to restore from the tar your data files!
Alan Porter
[ Parent | Reply to this comment ]
Yes. You get to have 15 slots where you can store 15 different keys, and each one will be able to unlock the partition. This allows different users to boot the system without actually sharing their keys.
Currently the LUKS scheme provides a method to add a new key (action luksAddKey to cryptsetup), and another method to remove and old one (action luksDelKey). Changing a key is just a matter of adding the new one and removing the old one.
This may look simple in theory, but the practical use is quite clumsy because you do not have any hint on which slot is allocated to which user (except maybe searching the logs).
[ Parent | Reply to this comment ]
Dave Vehrs did something similar (see http://www.debian-administration.org/articles/179) earlier (it was actually putting a full-blown encrypted-debian-on-a-stick).
He got lots of useful feedback and used that to improve the documentation and process, now at http://www.feraga.com.
[ Parent | Reply to this comment ]
Good article: you managed to show simple steps that lead to an effective result!
For sake of completeness, I think a note should be added just before the end of Part II, about formatting the newly created partitions:
# mkfs.ext3 /dev/vg/root # mkfs.ext3 /dev/vg/myspace
Then I cannot understand why you backed up the /home to the system tar and not to the data tar. As well as I do not understand the reason for backing up things under /media: either they are empty mountpoints and then they can be created anew with a simple mkdir, or they are bound to a mounted external storage, which will not be affected by changes to the local disk structure. In eiher cases I do not see the need for backing up.
Finally, you dismissed the argument LVM-over-luks vs. luks-over-LVM with just a few words. Has anybody more info/benchmark/comments about that?
[ Parent | Reply to this comment ]
The question here, since I'm new to the site, is how do I correct something? I can't seem to find any edit methods...
About backing up the /home to the system tar and not the data tar, the question is philosophical! I regard the /home more as a system directory than a data directory, because I don't keep any data in /home, but in another partition which I call 'The Data Partition' ;-)
About the mountpoints, you're right again. You can just create them with a couple of mkdirs...
Lastly, about the LVM over luks vs luks-over-LVM, I dismissed it because I did not have any info about it, nor could I find any on the internet. So, I decided to go the debian way.
Thanks for the feedback!
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
There is a link "Edit Article" in the right-hand menu-bar - amazing how many people fail to spot it. I'll make it bold later ;)
[ Parent | Reply to this comment ]
I thought something about the LVM over luks vs luks-over-LVM. What about resizing your partitions?
In my opinion if you have LVM on an encrypted virtual device you will have a issue if you want to resize it. I think you can't take advantage of the features of LVM in this situation. It's easy to join phisical discs online with LVM because LVM can cope with that stuff but if you have LVM inside one partition it will be harder to resize it. I read this way in http://www.hermann-uwe.de/blog/resizing-a-dm-crypt-lvm-ext3-parti tion.
(He uses the Debian way)
What do you think about?
[ Parent | Reply to this comment ]
Your computer is shutdown. You leave home.
CIA sneaks in. They boot with a live-cd.
They mount your /boot partition, unpack
your initrd image, and they add some
(trivial) code, so that your passphrase
is written to the /boot partition, before
it is passed to cryptsetup. They pack back
the image, and replace the existing one.
You return from home, turn on your computer.
You are asked for the passphrase, you give it,
it is written to /boot, it is passed to cryptsetup,
and all works fine.
Next day, you leave home, CIA breaks in and
grabs your computer... Hasta la vista baby!
The solution is to boot from a boot partition
on some kind of usb drive which you always carry
on you.
[ Parent | Reply to this comment ]
Then, at each system startup just verify the /boot files against their checksums. If you find that some file has changed you know that someone has been visiting you...
[ Parent | Reply to this comment ]
I created the /root/proj/boot_integrity/ directory.
The concept is that the /boot file's checksums will be stored there, inside the "boot_partition_checksums" file before the PC halts.
I then created a primitive (I hate /bin/sh scripting) script:
# cat /etc/init.d/calculate_n_check_hashes
#! /bin/sh
### BEGIN INIT INFO -- BY GPALL
# Provides: calculate_n_check_hashes
# Short-Description: Calculate /boot checksums on halt and verify them on startup
### END INIT INFO
PATH=/sbin:/bin
CSF=/root/proj/boot_integrity/boot_partition_checksums
case "$1" in
start)
echo "Verifying /boot checksums..."
VERIF=`/usr/bin/sha1sum -c $CSF`
if [ "$?" -ne "0" ]; then
echo "*********************************************************** *****************"
echo "*************** WARNING! /boot checksum verification FAILED! ***************"
echo "*********************************************************** *****************"
/usr/bin/sha1sum -c $CSF | /bin/grep -v ": OK"
echo "*********************************************************** *****************"
echo "*************** WARNING! /boot checksum verification FAILED! ***************"
echo "*********************************************************** *****************"
/bin/sleep 3600
exit 1
else
echo "/boot checksums successfully verified..."
fi
;;
stop)
/usr/bin/find /boot/ -type f -exec /usr/bin/sha1sum \{} \; > $CSF
echo "Stored /boot checksums"
;;
*)
echo "Usage: /etc/init.d/calculate_n_check_hashes {start|stop}"
exit 1
;;
esac
exit 0
Lastly, I installed it:
# cd /etc/init.d
# update-rc.d calculate_n_check_hashes defaults 40
On your system, '40' may need to be something else. The concept is to start the script (checksum verifying) after the filesystems have been mounted, and stop it (checksum calculation) just before filesystem unmounting.
You can now be sure that KGB has not planted something bad in your initrd...
[ Parent | Reply to this comment ]
Allow me to ask, how did you find out that a file named cryptroot with the mentioned content had to be created? Could the contents of that file also have gone to the menu.lst?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]