Summary: | sys-kernel/genkernel: initramfs does not open luks container if gpg-encrypted passphases are used | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Nicolas Schlumberger <n.schlumberger> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED OBSOLETE | ||
Severity: | minor | CC: | schism, zerochaos |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | initrd.scripts fix for gpg encrypted passphrases |
Description
Nicolas Schlumberger
2011-07-03 12:01:00 UTC
Created attachment 278917 [details, diff]
initrd.scripts fix for gpg encrypted passphrases
applying the attached patch to /usr/share/genkernel/defaults/initrd.scripts fixes the named issue.
Adding dacook to CC - in his interest I hope. (In reply to comment #0) > using gpg ecnrypted passphrases, initramfs provided by genkernel-3.4.16 built > with genkernel --luks --gpg all does not open the luks container. Please describe what you experience, instead. > removing/disabling one line in initrd.scripts does fix the issue. (see patch > below) Please explain the problem of the current cryptsetup_options="-d -" . Does cryptsetup_options="--key-file -" do any better? To my surprise I see two conflicting definitions of parameter -d in cryptsetup(8). --key-file, -d [..] --keyfile-size, -d value [..] I haven't looked at cryptsetup code, yet. Thanks for the reply. (In reply to comment #2) > Please describe what you experience, instead. > kernel and initrd boot, then I get the following output >> Activating mdev >> Using / key device /dev/sda5. >> Removable device /dev/sda5 mounted. >> /gsys.gpg on device /dev/sda5 found enter passphrase: <enter password> No key available with this passphrase >> LUKS device /dev/sda7 opened >> Using / key device /dev/sda5. >> Removable device /dev/sda5 mounted. >> /gswap.gpg on device /dev/sda5 found enter passphrase: <enter password> No key available with this passphrase >> LUKS device /dev/sda6 opened ls: /dev/mapper/swap: No such file or directory >>Determining root device... !! Block Device /dev/mapper/root is not a valid root device !! Could not find the root block device in . root block device() :: if I go into the shell, I see that neither swap not root are present in /dev/mapper. > > Please explain the problem of the current cryptsetup_options="-d -" . > > Does cryptsetup_options="--key-file -" do any better? > > To my surprise I see two conflicting definitions of parameter -d in > cryptsetup(8). > > --key-file, -d > [..] > > --keyfile-size, -d value > [..] > > I haven't looked at cryptsetup code, yet. using --key-file - instead gives exactly the same error. opening the partition by hand, i use the following command: gpg -d --quiet /boot/gsys.gpg 2>/dev/null | cryptsetup luksOpen /dev/sda7 root there was never a need to specify the keyfile (-d, --key-file). What version of cryptsetup are you using? IIRC, genkernel borrows the local one. The problem is likely with cryptsetup chaging behavior/duplicating the option, and will probably exhibit even without a gpg-armored key if genkernel's initrd specifies the key with --key-file or -d. =sys-fs/cryptsetup-1.2.0-r1 Though I thought,that genkernel pulls it in on its own. I see, that I can run some tests, varying the cryptsetup version, to if it make any difference. Downgraded to sys-fs/cryptsetup-1.1.3-r3 (latest stable), rebuilt initramfs, and the result is the same. the encrypted passphrase gets decrypted, but cryptsetup is unable to open the container. I like also to refer to dmcrypt's mouting script: /lib/rcscripts/addons/dm-crypt-start.sh, and how it calls the cryptsetup. gpg key (line 157): gpg ${gpg_options} ${key} 2>/dev/null | cryptsetup ${options} ${arg1} ${arg2} ${arg3} key (line 170): cryptsetup ${options} -d ${key} ${arg1} ${arg2} ${arg3} passphrase (line 174): cryptsetup ${options} ${arg1} ${arg2} ${arg3} and here too, there is no need to call cryptsetup with "-d -" to inject the key. Ok, intead of just commenting that part out (as proposed in patch), it may as well just be deleted. Regards nico I'm not yet comfortable with simply removing it (for nico's benefit, I provided the GPG initrd functionality). This represents a change in cryptsetup's behavior, and as with all cryptographic changes we should tread carefully. My concern here is that cryptsetup is not receiving the actual key material (or all of it) and using it properly, newlines and all - I need to test what it's doing more. dacook, I perfectly understand. I already appreciate, that I was able to use genkernel instead of rolling my own initramfs. I used an article on gentoo-wiki for the initial setup, that's where I got the idea, that -d flag is not needed. See [1] for how to setup the mappings, and how to open the container afterwards. I know - it is not an official gentoo documentation. Is there one on the subject? [1] http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Creating_the_mapping.28s.29 Is there anything I help/test? I am currently running a second setup with only an ecrypted swap - not root - and it shows the same behavior. Be also advised, that both setups are running full (hardened) ~amd64, though with a vanilla/gentoo kernel. cheers nico this is a super old bug, but "dogpg" has been supported for a while now. |