Dear maintainers, for my company notebook, I needed to encrypt the LUKS key for my root partition (double security: You need both the USB stick with the key and the password). Enclosed is a patch for genkernel-3.4.9's initrd.scripts file which implements the additional decryption step. Furthermore, if you use the same key for both root and swap partition, the decrypted data is used for mounting both, so you don't have to type in your passphrase twice. For my installation, I added the gpg binary via genkernel's overlay feature - I haven't made any adpations there (yet). I hope you find the patch useful! Reproducible: Always Steps to Reproduce:
Created attachment 149942 [details, diff] Patch for initrd.scripts Expects (statically linked) gpg binary in /sbin/gpg and a dummy gpg directory in /.gpg
So this is different than bug #162962 right? Also, please apply patches against the latest version, not the latest stable. Does this patch apply to SVN? (You can checkout the SVN anonymously)
Created attachment 150228 [details, diff] Patch against svn
(In reply to comment #2) > So this is different than bug #162962 right? Yes, it is. #162962 contained the enhancement for key material from an external source (like an USB stick). My patch allows this key to be additionally encrypted with gpg (usually in symmetric cipher mode). > Also, please apply patches against the latest version, not the latest stable. > Does this patch apply to SVN? (You can checkout the SVN anonymously) Checked it against the current svn; only a minor line number skew.
OK. I apologize that this has taken so long to get to doing. We've moved to a new repository at git://git.wolf31o2.org/projs/genkernel.git and are working towards 3.4.11's release. I'd love to get all of this support into genkernel.
Created attachment 200632 [details, diff] gpg support Here's a patch that 100% integrates GPG into genkernel. It doesn't add a man entrie, but the rest (compile, etc.) is there. It also avoids using temporary files by using '-d -' on cryptsetup - note that cryptsetup handles that differently than normal STDIN operation. Note that the smallest static build of gpg I can work up is still 1.2MB for x86 and 1.5MB for amd64, meaning it increases the size of the initrd by a lot. Someone needs to write a decrypt-only applet for busybox, but until then this will have to do.
Is there any future for this? It's working well for me, but if you have a concern with any of it I'd be glad to fix things... Basic use: 1. Patch genkernel and modify ebuild, adding a VERSION_GPG of 1.4.9 to the ebuild and relevant entries following those already there (that's a big hand-wave) 2. Add '--gpg' to your call to genkernel in addition to '--luks' 3. Create a LUKS key (outside this scope), then perform the following: # gpg --encrypt --symmetric /path/to/LUKS-key > /path/to/LUKS-key.gpg 4. Re-point the root_key argument to the new .gpg key 5. Boot GPG upstream has repeatedly recommended use of the 1.4 series for embedded use such as this, hence sticking to the old version. Version 1.4.10 fixes a few autoconf problems from 1.4.9, so this precise patch may not work for it. I can re-tool it for that if there's interest. Note that this doesn't add any boot-time arguments and relies on the key being strictly named '.gpg'. This was an intentional decision to enable transparent transition from the current model of leaving cleartext keys on-disk.
I find this very useful indeed; is there any chance to see it in portage?
playing with patch found at Comment #6, I was able to boot with genkernel without problem for /root device, while the following swap is not decrypted (basically, the behaviour is like the decrypted pass is not good. But this is not likely to be the reason, as both root and swap are encrypted with the same key and if I try to decrypt swap with luksOpen after the successful boot it works without problem. I tried to debug this behaviour but without success. Looking at the patch I'm puzzled about what happens if /dev/tty exists and luksOpen is called twice, once for root and once for swap. Basically, tty is moved to tty.org and never restored...
Setting /dev/tty to 'c 5 1' is an artifact of an old script I used at one point and reflects that, in the limited init state, the current tty is actually the system console - this allows GPG's tty control when asking for a password to work when booting with a VT, serial connection, or otherwise. It's not as elegant as it could be, but unless you are starting daemons during the preinit phase, you shouldn't worry about it (and it doesn't really need to be restored). That said, please provide further information on how you're trying to use this to encrypt, especially your kernel command line. If there's a bug I'll fix it, and once that's worked out I'll post the (nominally different) patch for 1.4.10 as well as an ebuild based on the current 906 one in-tree.
thanks for your answer! this is the scenario: I've a mmc card that holds the gpg ecrypted key used to open root partition. with your patched init script, this works just fine. (besides annoyng warning messages about udevadm not existing) now I'm trying to use an encrypted swap partition that allows me to use hibernation. So I built swap in the same way I built root and (as testing) I'm using the same gpg encrypted pass file. Of course init script stops twice to ask me gpg pass but no matter what it luksOpen always fails with swap partition. (If I retry at command line with the same syntax all works just fine) (It would also be nice if for the second partition the script first tries to use the previously entered gpg pass, just to avoid to enter it twice if it is the same, but this is another story :) ) the kernel command line is the following: title=Gentoo Linux (2.6.31.4) kernel /kernel-genkernel-x86-2.6.31.4 root_keydev=/dev/mmcblk0p1 root_key=rootkey.gpg crypt_root=/dev/sda5 real_root=/dev/mapper/root swap_keydev=/dev/mmcblk0p1 swap_key=rootkey.gpg crypt_swap=/dev/sda7 initrd /initramfs-genkernel-x86-2.6.31.4 now I'm trying a (I know, less secure) approach, that is to have a swap key on root partition, like this: kernel /kernel-genkernel-x86-2.6.31.4 root_keydev=/dev/mmcblk0p1 root_key=rootkey.gpg crypt_root=/dev/sda5 real_root=/dev/mapper/root swap_keydev=/dev/mapper/root swap_key=/keys/swap.key crypt_swap=/dev/sda7 This works, even if the script spits out a sh error "unknown command .gpg" (writing based on what I can recall, basically it seems that the init script tries to launch ".gpg" command.) Let me know if you need other informations.
(In reply to comment #7) Thanks a lot for your patch dacook - this work great on my eeepc since a month (just a small artefact on tty about udevadm without consequences) Tahnks again to chris for your job with genkernel - I hope you'll have the time to add it in the tree - for the next release maybe ? ^^ - so anyway, really thanks
Created attachment 208338 [details, diff] latest GPG patch Latest update to the patchset, tooled for gnupg-1.4.10. I cannot replicate the crypt_swap issue from comment #11 - please make sure you're properly encrypting your swap: # gpg --decrypt /path/to/key.gpg | cryptsetup -d - luksFormat /path/to/swap - That said, I can't say I understand why you're using a permanent key on your swap, unless you're trying to resume out of hibernation on it. Better to use the randomly-keyed setup from /etc/init.d/dmcrypt or do as I do and create an LVM volume on top of your LUKS device. The udevadm artifact comment #12 notes is actually a message from cryptsetup and not GPG - cryptsetup is hard-coded to try to execute /sbin/udevadm to settle devices. Ebuild patch forthcoming
Created attachment 208341 [details, diff] ebuild patch A brief patch to the current 3.4.10.906 ebuild to illustrate the changes necessary. Still lacking: man page entry and interest in doing it.
Comment on attachment 208338 [details, diff] latest GPG patch Renamed patch to match the ebuild, note that it needs to go into ${FILESDIR}.
(In reply to comment #13) > Created an attachment (id=208338) [details] > latest GPG patch > > Latest update to the patchset, tooled for gnupg-1.4.10. > > I cannot replicate the crypt_swap issue from comment #11 - please make sure > you're properly encrypting your swap: I'll try asap, just to make sure that is working as expected. > > # gpg --decrypt /path/to/key.gpg | cryptsetup -d - luksFormat /path/to/swap - > > That said, I can't say I understand why you're using a permanent key on your > swap, unless you're trying to resume out of hibernation on it. Yes, that's the reason. I'm still fighting to have a reliable hibernation resume, it works only half of the times :) , but of course I need a permanent key for swap. > > Ebuild patch forthcoming > Thanks, I'll give it a try really soon.
Finally I had the time to test :) All works just fine, even swap partition (that in my case had some troubles, maybe related to some unknown problem on my side) Last patch just works, many thanks.
Created attachment 213301 [details, diff] 3.4.10.907 gpg patch GPG patch against 907, bonus: added a genkernel(8) entry. Can't think of anything else to add.
Created attachment 213302 [details, diff] ebuild patch Patch against the in-tree ebuild. Put the genkernel patch in ${FILESDIR} and let 'er rip.
Hello, I'm testing the latest ebuild, but I'm unable to use the key.gpg. After booting, the system is asking me again and again, the device that contain the luks partition, the device that contains the lucks key and the name of the lucks key. Also if all of them are correct, it simply loop. When I change the lucks key from key.gpg to key, it boot correctly without asking me the password of course. Any help would be appreciated. Thank you, Lorenzo
Please merge this patch, it is indeed useful and works just fine :)
(In reply to comment #21) > Please merge this patch, it is indeed useful and works just fine :) > Hello Fabio, are you from Italy? I'm too, maybe we can discuss over some IM about that. Actually I've tested the patched ebuild, and the latest is the one that does not work for me. There is any information that I can provide to find what's wrong? Best regards, Lorenzo Lolli
Lorenzo: Without any further information, it sounds like you didn't add '--gpg' to your call to genkernel when you were building your initrd. You should be doing something to the effect of: # genkernel --luks --gpg --lvm all
Thank you dacook, I've found the problem, the patch wasn't correctly applied. After fixing that it works as expected! Very good job, thank you again :) Lorenzo
Yesterday, after a kernel recompilation, I discovered that boot decryption is no longer working. After recovering from a sudden heart attack :) , I found that the command line sequence: gpg --decrypt mykey.gpg | cryptsetup luksOpen /dev/sda5 vol works, while the similar gpg --decrypt mykey.gpg | cryptsetup -d - luksOpen /dev/sda5 vol does not and if I am right the latter form is used in init script. Since I didn't changed the key on the hardisk, I think that some tool has changed behaviour. In fact, looking at this: http://code.google.com/p/cryptsetup/wiki/Cryptsetup112 where you can read This release fixes a regression (introduced in 1.1.1 version) in handling key files containing new line characters (affects only files read from standard input). Cryptsetup can accept passphrase on stdin (standard input). Handling of new line (\n) character is defined by input specification: * if keyfile is specified as "-" (using --key-file=- of by positional argument in luksFormat and luksAddKey, like cat file | cryptsetup --key-file=- <action> ), input is processed as normal binary file and no new line is interpreted. * if there is no key file specification (with default input from stdin pipe like echo passphrase | cryptsetup <action> ) input is processed as input from terminal, reading will stop after new line is detected. It seems likely that the lines that have something like cryptsetup_options="-d -" in this patch must be modified to fix this behaviour. as temporary workaround, if the boot process stops, you can drop to the shell, enter by hand somethink like gpg --decrypt mykey.gpg | cryptsetup luksOpen /dev/sda5 vol exit the shell and proceed with a "q". Can someone confirm or deny this reconstruction? thanks.
I'd initially run into this issue with the hardened-sources-2.6.33-r2 kernel and cryptsetup-1.1.1. No error (dmesg or otherwise), just didn't decrypt the volume, but it worked fine with -r1. Clearing genkernel's binary cache and forcing a re-build of the initrd to incorporate cryptsetup-1.1.2 fixed the issue for me. Don't know why 2.6.33-r2 and 1.1.1 didn't like each other with the '-d -' syntax, but the latest on both does work. Hence, I'm not seeing a need to change this thus far.
Wanted to add a "works for me" with genkernel-3.4.10.907. Thanks!
PS: Adding keyword "Inclusion" and "[patch] " prefix to better show this bugs nature in searches...
This bug is opened since 2008, and the patch works just fine and indeed useful. What needs to be done to have it in standard ebuild?
(In reply to comment #29) > This bug is opened since 2008 I agree that's bad, yes. >, and the patch works just fine and indeed useful. To be clear, which patch are you referring to? Are we talking about genkernel-3.4.10.907-gpg.patch? Any ideas on the status of initrd.scripts-genkernel-svn.diff? > What needs to be done to have it in standard ebuild? The patch needs review and some sort of testing by someone understanding the patches details. That means experience in all of the areas it touches: Bash, Luks, GPG, tty's, genkernel itself, maybe more. I for instance am no expert on all of these, yet. I may still find a bit of time for this, we'll have to see. The first thing I spot that could be improved is this Bash part: [ $(echo ${LUKS_KEY} | grep -o '.gpg$') == ".gpg" ] I don't see need for grep here - we can save that. Is anyone (dacook especially but not only) interested in working on this patch in a dedicated git branch on http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=summary? If you're interested please send your full name, nick name and SSH pubkey to <genkernel@g.o.>. Thanks!
Eh, I have my own overlay and it works for me. I actually follow genkernel's git tree as well, so little speed lost there. Never owned the bug so couldn't add the requested tags, but I've pestered the owner of the package (per metadata.xml) several times with no return. My patches replace the old ones from Stefan Schlott, I simply couldn't mark his as invalid or superceded. The grep is actually necessary; the '==' bashism could be eliminated for '=', but I didn't find a good way to do regex-ish matching on filenames with non-bash shells. The intent is to make it as transparent as possible - you use normally-named keys, you get normal LUKS behavior. You GPG-encrypt your key and name it '$foo.gpg', you get GPG behavior.
Comment on attachment 150228 [details, diff] Patch against svn (In reply to comment #31) > Eh, I have my own overlay and it works for me. On a side note: you can have your overlay in Layman, just send a mail to <overlays@g.o.>. > I actually follow genkernel's > git tree as well, so little speed lost there. I'm not sure what you mean by speed loss. Do you want Git access with us? Alternatively, is your Git clone avaliable for pulling somewhere? On another side note: have you seen the new experimental branch exposed by the 99999er ebuild (five nines)? > Never owned the bug so couldn't > add the requested tags, but I've pestered the owner of the package (per > metadata.xml) several times with no return. My patches replace the old ones > from Stefan Schlott, I simply couldn't mark his as invalid or superceded. Just did that for you. > The grep is actually necessary; the '==' bashism could be eliminated for '=', > but I didn't find a good way to do regex-ish matching on filenames with > non-bash shells. I was thinking of something like [[ "abc.gpg" = *".gpg" ]] && echo MATCH but I fail to convert it to plain [ or test. I'm unsure if grep '\.gpg$' <<<"abc.gpg" >/dev/null && echo MATCH is any better. But maybe let's take that off the bug.
I prefer to control my distribution, so don't publish the overlay but to those I know. Git access isn't necessary; this may well be the only contrib I have for this project. Have not seen the experimental version, but will patch/develop as necessary against it if you give me the URL. Will send you my repo directly. Certainly open to tweaks & addressing any concerns; I spent a good amount of time exploring the limitations of the genkernel initrd environment before making many choices, but that doesn't make them infalliable.
@all Check genkernel-99999 (five nines) to get this before the next release.
