logo

 

This site is now 100% read-only, and retired.

How To Migrate to a full encrypted LVM system

Posted by gpall on Mon 28 Jan 2008 at 15:07

Tags: , , ,

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.

Lastly, change your fstab file in rootfs/etc so that it points to your new root device: /dev/vg/root.

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!

 

 

 

#
Re: How To Migrate to a full encrypted LVM system
Posted by Anonymous (199.72.xx.xx) on Mon 28 Jan 2008 at 18:52
I thought one of the reasons for using LUKS was that you *could* change your passphrase. In fact, you should be able to create up to 15 different passphrases for the same encrpyted disk partition!

Alan Porter

[ Parent ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by mcortese (213.70.xx.xx) on Wed 30 Jan 2008 at 15:01
[ View Weblogs ]

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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by Anonymous (59.176.xx.xx) on Tue 29 Jan 2008 at 06:30
Lovely.

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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by mcortese (213.70.xx.xx) on Tue 29 Jan 2008 at 10:34
[ View Weblogs ]

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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by gpall (155.207.xx.xx) on Tue 29 Jan 2008 at 10:47
[ View Weblogs ]
You are right about formatting the partitions, I forgot to mention it :-)
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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by Steve (80.68.xx.xx) on Tue 29 Jan 2008 at 15:28
[ 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 ;)

Steve

[ Parent ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by Anonymous (83.41.xx.xx) on Sun 18 May 2008 at 14:21
Hello.
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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by Anonymous (69.84.xx.xx) on Tue 9 Sep 2008 at 00:51
There's no need to decide Luks over LVM vs LVM over Luks: use both. Use LVM on the bottom to manage your raw media and present it as a single block. Layer Luks on top of LVM to encrypt that one block, and then LVM on top of Luks for your data volumes. This setup works with the latest version of the installer and kernel. My system has everything but /boot encrypted, like this:

RAID <- LVM <- LUKS <- LVM <- [logical volumes for /, swap, etc]

[ Parent ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by gpall (79.103.xx.xx) on Wed 20 Feb 2008 at 17:09
[ View Weblogs ]
Of course, one should note the following scenario:

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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by gpall (85.74.xx.xx) on Sat 19 Apr 2008 at 19:38
[ View Weblogs ]
Another solution is to calculate checksums of all your files in your /boot partition and save them somewhere in the encrypted space, just before system halt.

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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by gpall (79.103.xx.xx) on Tue 22 Apr 2008 at 17:17
[ View Weblogs ]
So, at last I came up with a primitive but efficient method to check if my /boot files, the only un-encrypted files have been tampered with.

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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by Anonymous (62.52.xx.xx) on Tue 29 Mar 2011 at 16:27
Additionally you must protect the bootstrap loader that loads the bootfiles or you win nothing... Your CIA might modify the boostrap loader so that it restores itself after they got the password. The password itself can be stored on *any* sector on the harddrive or be stored in a sector marked in the defect list of your drive. Anyway you would not recognize it even if they overwrite some of the encrypted sectors because when the failure occurs you would hate the world for the failure but not know that that space had been used to store the password.

PC and harddrive architecture just does not have any chance to prevent those kind of attacks. And believe me that if you have something the CIA wants, they will get it. No matter what you had done before to protect yourself.

it-security is not about standards but about getting around standards.

[ Parent ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by Anonymous (92.75.xx.xx) on Sun 3 Aug 2008 at 19:42
Thanks for this guide. It helped me solve a booting problem with the lenny beta2 installer.
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 ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by gpall (155.207.xx.xx) on Mon 11 Aug 2008 at 09:50
[ View Weblogs ]
I found a how-to that was mentioning this file along with its contents. But I have now deleted it from my system as it doesn't look to be needed. I updated the article accordingly.

[ Parent ]

#
Re: How To Migrate to a full encrypted LVM system
Posted by brownster (2.97.xx.xx) on Wed 16 Jan 2013 at 11:45
Thank you for posting this how to, my system is now converted.
I made a few mistakes along the way but learnt a great deal along the way :)
Cheers,
Brownster

[ Parent ]