LVM on LUKS with detached header
CidKramer opened this issue · comments
Hey,
Thank you for this project.
I'm trying to build a Gentoo install at the moment and hoping to use your script for the initramfs. I'm just having a hard time following the documentation and what precisely I need to do to get my setup to work.
I've got LVM on LUKS and using a detached header on a separate device, which is the boot device.
so /dev/sda1 is LUKS encrypted
and header.img is the detached header located on /dev/sdb1
then /dev/mapper/myvol-gentoo is the LVM volume I want to use as root
I'm using just a regular passphrase, no key file. Would you be able provide an example of what kernel parameters I should be using?
Cheers
CK
Hello,
First, let me see the sample configuration file because this is where
simple examples are shown and wrote down for a use case.
use lvm and luks will require setting up lvm and luks. Volume
group is myvol, logical volume gentoo, password for luks.
luks=pwd root=myvol-gentoo
lvm=mypv-sda1
Second, you wont be able to use a detached header with a pssword mode.
This is only available when using removable device (which become... non
removable when detached header is enabled!). So, a keyfile is needed
here.
Third, if you go the detached header way, you should use UUID or at least
LABEL instead of plain device node to avoid header mismatch. And then,
the lvm kernel argument would become lvm=mypv-sda1+sdb1 (but you
should be using UUID instead!)
Now, it's really a bad idea to use lvm on top of luks; I will be
throwing away my lvm setup when I have a chance to overhaul my disk
setup. Arno Wagner,-the maintainer of cryptsetup do not,-rightly, do
not recommend using lvm. I am currently having file leaks with that over
engineered cluster *$#@ of lvm. So, take note of this. Either partition
drives with care; or use an over engineered filesustem (btrfs, zfs.)
Good luck!
PS: And lastly, you can set that kernel command line argument in the
configuration file; so nothing to append on the kernel command line
across various boot loader. The environment could be unset with
env=:lvm:luks:root: and then append whatever necessary.
On Mon, Jul 25, 2016 at 04:39:13AM -0700, CidKramer wrote:
Hey,
Thank you for this project.
I'm trying to build a Gentoo install at the moment and hoping to use your script for the initramfs. I'm just having a hard time following the documentation and what precisely I need to do to get my setup to work.
I've got LVM on LUKS and using a detached header on a separate device, which is the boot device.
so /dev/sda1 is LUKS encrypted
and header.img is the detached header located on /dev/sdb1
then /dev/mapper/myvol-gentoo is the LVM volume I want to use as rootI'm using just a regular passphrase, no key file. Would you be able provide an example of what kernel parameters I should be using?
Cheers
CK
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#41
Hey tokiclover,
Thanks for the response. It was much more informative than I was expecting ^^
Hmm for my use case I would like to keep the detached header setup I have with the passphrase. Seems like a more secure set up if the header file is somewhere else than the encrypted drive.
So to clarify, its not possible to use your script to build an initramfs that can load a detached header to work with a passphrase?
I had something set up before that I gleaned from the ArchWiki:
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Encrypted_system_using_a_remote_LUKS_header
But that was using mkinitcpio. I did build an initramfs using your script though and it was alot prettier ahah though I couldn't boot.
Actually you cound set up something. My previous example was bogus; but
basically you have to use a keyfile for a regular file; or else, use
another device (and then use UUID in my previous example.)
Botting with a detached header is not that good idead because the
removable device should not be removable anymore. If such device is
removed while a device is active... undefined behavior would occur and
other bad things.
And extending a detached header as regular file is not that difficult to
support either... it's not a good idea. And it's not more secure because
the detached header shall be there all the time. It's more complicated
for a boot device. It's just that it can become usefull when using
multiple device with the same header... Setup a single device with your
setup and then deploy the same header everywhere. Do you follow? Not
more secure... much like more deployable.
On Wed, Jul 27, 2016 at 02:41:31PM -0700, CidKramer wrote:
Hey tokiclover,
Thanks for the response. It was much more informative than I was expecting ^^
Hmm for my use case I would like to keep the detached header setup I have with the passphrase. Seems like a more secure set up if the header file is somewhere else than the encrypted drive.
So to clarify, its not possible to use your script to build an initramfs that can load a detached header to work with a passphrase?
I had something set up before that I gleaned from the ArchWiki:
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Encrypted_system_using_a_remote_LUKS_headerBut that was using mkinitcpio. I did build an initramfs using your script though and it was alot prettier ahah though I couldn't boot.
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#41 (comment)
Wait, It was my understanding that once the device had been opened with cryptsetup the header is no longer needed so long as that device is open. I've been running my system for awhile now with a detached header on a sd card which isn't mounted after the main system boots.
I think the detached header is more secure. It's like a form of two factor authentication no? For example if I leave my laptop with header on the main hd in a hotel room. If an attacker steals it they just need to crack the password. However if I leave my laptop in a hotel room with the header on a removable device that I take with me then the attacker has no viable path to unlock the main system.
That was my thinking anyway. I'm not a expert by any means. Just enthusiastic about this stuff.
If everything is as you say,--whch I believed till... a few weeks
ago,--then it's indeed more secure. It's just that in the matter of
testing a few things a few weeks ago, I could not umount normaly a
device holding a detached header... It seemed that the detached header
was still being opened by somthing. I did not have yet the time to
investigate. This is why nothing is decided yet to remove that
detached header (as regular file) support or not.
Good luck.
Hello,
I'm trying to build a very similar setup and have chosen mkinitramfs-ll as some documents recommended it,
my setup consists of:
A crypted /dev/sda.
Inside it, there is a LVM setup with the root (/) LV, etc...
the LUKS header is embedded into the CPIO, located on /usr/header.img.
I'll move the header outside as soon as I get this "simpler?" setup working.
I've modified the init file itself, adding the cryptsetup and lvchange routines and I've been able to boot somehow, but as we would agree, this is not the right solution.
After reading man 1 mkinitramfs-ll, I'm trying to add luks=pwd:crypto-/dev/sda+/usr/header.img .
But it fails and begs me to input a "valid block device", it happens that to him, /dev/sda is not a valid one, so it keeps asking me.
After checking the code during hours from the rescue shell, My problem seems to come from the function "dmopen" which expects <map-dev+header> but as soon as it runs, calls 'blk "$_dev" "_dev"'.
At this point in time, $_dev should have the "/dev/sda+/usr/header.img" part of the input var.
So moving to blk: blk keeps asking me to input a "valid block device" where it runs blkid for any input I provide, trying to find my input on the blkid list, unbeknownst to the fact that blkid will never list (as it seems on my system) a headerless block device. Is it a bug? or am I doing something wrong here?.
If you type "blkid /usr/header.img" then you can get a blkid return its uuid, but you can't ever verify that /dev/sda is the right block device for that header.img file, you have to cryptsetup open it and hope for a match.
As soon as I get this small roadblock solved, I'll advance to mount the lvm and root structures using the kernel/initramfs parameters, for now, I am stuck with the dirty hack writing directly onto /init to cryptomount.
TLDR: I think the blk function doesn't know how to check for a luks headerless block devices and enters an infinite loop asking for a device which it will not allow (blkid | sed...) [doesn't list my device as it is random-like] when it should accept it and try to cryptsetup open it. Maybe we should find a different way to check if something sd* or so is a block device?
Thank you for reading so far!
This is now fixed with commit 01ad732