LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Decrypting Multiple LUKS Volumes During Boot (http://www.linuxquestions.org/questions/slackware-14/decrypting-multiple-luks-volumes-during-boot-4175458550/)

flokofcgulls 04-17-2013 09:10 PM

Decrypting Multiple LUKS Volumes During Boot
 
I'm new to Slackware, with intermediate Linux skills. I've really taken a liking to the system, and I'm currently trying to reproduce my setup in a virtual machine before rolling it out to my systems over the summer. I've been steadily making progress, but I've been unable to gets my encryption setup fully working as it is on my laptop.

A little background on my setup...

I have a 128GB SSD, and a 750GB SATA drive. I have the SSD split into two 64GB partitions: one for Windows 7, and one for Linux. The SATA drive is split in a similar fashion, with half for Windows and the other half mounted as /home. I have the Windows side of things encrypted with Truecrypt, and Linux with LVM on LUKS. I also have a small unencrypted partition for /boot, including the Truecrypt bootloader that was copied to a file using the dd command.

Currently, if I boot to Windows, Grub is configured to chainload the Truecrypt bootloader from /boot, and proceeds as normal from there. When I select Linux, I'm prompted for the password to decrypt the root volume, and then the home volume is automatically decrypted using a keyfile stored within the root partition, which is specified in /etc/crypttab.

What I would like to do...

I'd like to recreate this setup using Slackware and LILO, but I haven't been able to get it fully working. Specifically, I'm at a point where the root volume is decrypted at boot, but then the /home volume is not.

I've been digging through documentation for the past week, between the Slack Book, the README_CRYPT.txt, various forums and blogs, but all the information I've found only explains how to do this for a single volume, and not more than one. I do currently have a crypttab file with entries for these but it seems to be ignored.

I suspect that the solution may have something to do with the initrd image that I built after the installation. I've noticed that the mkinitrd command in all the encryption documentation includes several options that are not listed in the manpage for mkinitrd. Specifically, I've seen -c, -f, -r, -C, and -L, just off the top of my head. I've been unable to locate any documentation on exactly what these do, other than "here's what to type", so I feel like if I could figure out what all these switches are doing to the initrd I might have something to experiment with a little more.

Hope I haven't overlooked something obvious, but I'm still learning the ins and outs of Linux system management, especially with building kernels and boot images. If anyone has any insight on this, or could at least nudge me in the right direction, it would be greatly appreciated.

Richard Cranium 04-17-2013 09:24 PM

try "/sbin/mkinitrd --help"

I guess you've read /etc/rc.d/rc.S already.

TracyTiger 04-17-2013 10:18 PM

Quote:

Originally Posted by flokofcgulls (Post 4933656)
I have the Windows side of things encrypted with Truecrypt, and Linux with LVM on LUKS.

I'd like to recreate this setup using Slackware and LILO, but I haven't been able to get it fully working. Specifically, I'm at a point where the root volume is decrypted at boot, but then the /home volume is not.

In addition to Richard's suggestion regarding mkinitrd some other general thoughts ...

Lilo needs to be re-run after every configuration change.

Since you've made it this far you've probably read README_CRYPT.TXT & README_LVM.TXT in the root directory of the Slackware release media.

Thanks to Alien Bob I learned NOT to use "root= " in lilo.conf as it is no longer needed and can cause problems. (Probably not your issue)

The file system used needs to be included when the initrd.gz file is created by mkinitrd (e.g. ext4).

It's sometimes better to use UUID in file system tabs when possible so that the correct disk drive is used.

Alien Bob 04-18-2013 02:23 AM

Quote:

Originally Posted by flokofcgulls (Post 4933656)
I'd like to recreate this setup using Slackware and LILO, but I haven't been able to get it fully working. Specifically, I'm at a point where the root volume is decrypted at boot, but then the /home volume is not.

The README_CRYPT.TXT file has a section called "Encrypting your '/home' partition". Perhaps you should read that.

Eric

STDOUBT 04-18-2013 03:00 AM

flokofcgulls,
Quote:

Specifically, I'm at a point where the root volume is decrypted at boot, but then the /home volume is not.
Hopefully not adding to your confusion, please see the section of README_CRYPT.TXT called "Combining LUKS and LVM". It seems your /root and /home are not part of the same volume group. If they were, they'd be decrypted together. In this case you would not use an /etc/crypttab.

GazL 04-18-2013 05:05 AM

/etc/crypttab is processed in rc.S after lvm initialisation. For this reason it's not much use for unlocking lvm PVs as the train will have already left the station.

You have 3 choices:
  1. Use mkinitrd -C option to unlock all PVs during the initrd phase.
  2. Encrypt at the LV level rather than the PV level - LVs can be unlocked in /etc/crypttab
  3. Change rc.S to include a second run of the lvm initialisation after the crypttab section - which will enable it to unlock lvm PVs.

Z038 04-19-2013 12:58 AM

Quote:

Originally Posted by Tracy Tiger (Post 4933679)
Thanks to Alien Bob I learned NOT to use "root= " in lilo.conf as it is no longer needed and can cause problems. (Probably not your issue)

Hi, I apologize to the OP for this off-topic tangent, but could someone explain what problems might be caused by specifying root= in lilo.conf?

I have it specified in my lilo.conf. It hasn't caused any problems I'm aware of, but I'm just wondering what the potential is.

flokofcgulls 04-19-2013 07:20 AM

Hey folks, just wanted to jump in for a moment and say thanks to everyone that has provided all these helpful replies!

I'm currently in the process of working through all of this new information, and I will report back with an update as soon as I have explored all of these options, which should be sometime over the weekend.

@Z038 - No need to apologize, I'm actually curious about this as well. I've always used GRUB in the past, so I'm learning about LILO alongside this process. As a scientist, I always like to know "why" things are the way they are, and how they affect other things.

flokofcgulls 04-20-2013 07:05 PM

OK, I finally had a chance to hack around with all of these suggestions for several hours today, and I believe I've figured it out!

Quote:

try "/sbin/mkinitrd --help"

I guess you've read /etc/rc.d/rc.S already.
I was under the assumption that the online man pages I had been reading were copied verbatim from the built-in system man pages. It turns out that this was incorrect, and the system documentation was FAR more comprehensive, and explained all the mkinitrd options, which helped to clarify what I was doing greatly.

I was also not aware of the rc.S file, and this turned out to be a critical piece of the puzzle, which I'll discuss in a moment.

Quote:

The README_CRYPT.TXT file has a section called "Encrypting your '/home' partition". Perhaps you should read that.
I had indeed been reading this file quite a bit, and it was very helpful in learning how Slackware handles LVM and LUKS. However, it only explained how to do either the /home, or the /root, but not both simultaneously with the non-root being automated.

Quote:

Hopefully not adding to your confusion, please see the section of README_CRYPT.TXT called "Combining LUKS and LVM". It seems your /root and /home are not part of the same volume group. If they were, they'd be decrypted together. In this case you would not use an /etc/crypttab.
This is correct, my /root and /home are in two separate volume groups. The reason for this is that I wanted to ensure the /root was on the SSD for performance reasons, and the /home was on the SATA drive exclusively. Way back when I did this the first time, I tried doing a single volume group and IIRC it caused some issues with having these cleanly separated.

Quote:

/etc/crypttab is processed in rc.S after lvm initialisation. For this reason it's not much use for unlocking lvm PVs as the train will have already left the station.

You have 3 choices:

Use mkinitrd -C option to unlock all PVs during the initrd phase.
Encrypt at the LV level rather than the PV level - LVs can be unlocked in /etc/crypttab
Change rc.S to include a second run of the lvm initialisation after the crypttab section - which will enable it to unlock lvm PVs.
While experimenting, I tried the -C option and added both of the encrypted partitions to the argument, as in "-C /dev/sda2:/dev/sda3" and this actually did get it working, but it required me to type the password two times because /root had not been mounted yet, and thus the keyfile for /home could not be read. The third option you mentioned, along with Richard Cranium's suggestion, ended up being the final piece that brought everything together.

I still need to write up some official documentation on how I did this, but here's a very brief summary of what I had to do:

1) Create two PV's, two VG's, and two LV's for /root and /home
2) Initialize both VG's using vgscan --mknodes and vgchange -ay
3) Install Slackware as normal
4) chroot to the new install before reboot
5) Create a keyfile, make it read-only to root, and add it to the encrypted /home partition
6) Create a crypttab file for just the /home partition, specifying the keyfile to use
7) Use the mkinitrd script to recommend a good initrd image
8) Edit the rc.S script by copying the entire LVM Init section, and pasting it further down just before the "mount non-root filesystems" section

By making the change to rc.S, I'm prompted for a password to unlock /root, and the vg for /root is activated and mounted; then, the script unlocks /home using the keyfile specified in crypttab, and runs the LVM initialization a second time to activate the newly-unlocked vg for /home before it is mounted. Since the keyfile is actually stored within the encrypted /root, I believe this is still reasonably secure.

It's quite possible there may be a better way to go about this, so if anyone would like to add any additional insight I'd love to hear how this might be improved.

I'd like to thank everyone who offered suggestions to help me figure this out, definitely the friendliest forum experience I've had in quite some time. I may come back and post an official guide for this once I've written one up for myself, if you feel it would be beneficial to others.

STDOUBT 04-20-2013 08:36 PM

Quote:

This is correct, my /root and /home are in two separate volume groups. The reason for this is that I wanted to ensure the /root was on the SSD for performance reasons, and the /home was on the SATA drive exclusively. Way back when I did this the first time, I tried doing a single volume group and IIRC it caused some issues with having these cleanly separated.
Just to mention, in case I don't understand the way you did this "the first time", you can include partitions from separate hard drives into a single volume group. For example, your /root on sda1, and your /home on sdb1 could be: /dev/mapper/MyCrypt-root, /dev/mapper/MyCrypt-home, etc.

Richard Cranium 04-20-2013 09:06 PM

If you are using an initrd image for your boot, then you should also read the initrd-tree/init file. It appears to have the ability to do what you want in there.

TracyTiger 04-20-2013 11:53 PM

Lilo "root= " Issue
 
Quote:

Originally Posted by Z038 (Post 4934547)
Hi, I apologize to the OP for this off-topic tangent, but could someone explain what problems might be caused by specifying root= in lilo.conf?

The problem solved by Alien Bob's suggestion to remove root= in lilo.conf is summarized in my post # 11 in the following thread which has good information from GazL in post # 4 on the workings of Slack.

https://www.linuxquestions.org/quest...6/#post4801795

This was last Fall and things may have changed regarding this topic since then.


All times are GMT -5. The time now is 09:46 PM.