| Summary: | genkernel: feed LUKS with key from removable device (linuxrc patch) | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Thomas Bettler <thomas.bettler> |
| Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | nelson.batalha |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
genkernel-initrd_provide_luks_key.patch
genkernel_3.4.6.patch hopefully last patch, improved and tested this a lot genkernel_key_07.patch genkernel_key_08.patch genkernel_key_085.patch genkernel_key_09.patch correct latest svn changes still small corrections |
||
|
Description
Thomas Bettler
2007-01-20 18:44:06 UTC
Created attachment 107569 [details, diff]
genkernel-initrd_provide_luks_key.patch
The patch is against genkernel-3.4.6
Created attachment 113106 [details, diff]
genkernel_3.4.6.patch
Correct some mistakes. This one works out of the box.
Sorry that this has been so long since you posted this. I've been terribly busy, and had to learn how in the world LUKS works so I can support it in genkernel. What I was wondering is if you could modify this to take into account the changes made to genkernel for bug #174294 which has already been added. I'd love to have it default to reading from /livecd if a key isn't specified. If you don't have time, I can do it, but it'll definitely take me long to get to than it would probably take you to do it. Hi Chris These few lines of code look really pretty. I'd like to adapt my patch to match against HEAD, but for the next few weeks I simply can't manage to do it. If you're willing to wait until then, I will try to do it myself. Thanks a lot for maintenance. Hi, I'll do it (I did bug #174294 and read your patch) I know exactly what needs to be done. Here it is. (bugzilla bug didn't let me submit as patch) http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/genkernel_key_03.patch It has some minor corrections, both to your code and existing one. I tested with and without a keyfile on some encrypted livecds. In the next patch I'll implement the crypt_silent argument completely, and do some code cleaning/abstraction. Thank you Nelson for your work on the patch. Yes, sure, some more abstraction of the key device recognition and the encryption process is warmly welcome. You may go for it... (I for the moment still got no time, so feel free =];-) (In reply to comment #7) Ok, done most. But could you explain the need to have another two boot options to have a separate key for the swap? Just trying to limit the boot args, as it'll have to show up in the man page, and later was thinking of writing a luks guide. I mean, immediately we think that having two keys is more secure. But an attacker would always try to decrypt the root first (and there is almost nothing the swap has the root doesn't), so mathematically the chances of getting to your files are the same. Correct me if I'm wrong. Hmm. I just never looked at it like this, sine I chose a different key for each partition. - Mathematically your absolutely right, just that I practically chose a different way.
Anyway you make me thinking of sharing one key among them...
If you manage to detect which partitions {root,swap} are encrypted and try the key on them you would make me perfectly happy.
Created attachment 127069 [details, diff] hopefully last patch, improved and tested this a lot (Actually if you have a key for each partition it's different, but let's just keep swap and root with the same key for now) Ok, I've done considerable changes since the previous patch. Here are the changes: # openLUKS from Thomas Bettler completely rewritten, it's smaller and acts exactly as is supposed to ;) (I'm talking about the possible paths of error/decryption in openLUKS, device naming got wrong, etc). Automatic key finding now works at the beginning (see man page) or if the given key device is not found. # added whereis(), replaces 5 instances of similar code. # also abstracted things like findkeymount,findcdmount, device lists >> findmediamount # crypt_silent implemented # man page updated # other things from Thomas Bettler (bug 162962) with some micro changes. in general corrected # tests like [ "${variable}" -eq '1' ] give an ugly ouput if variable is not defined (like NORESUME). Corrected to !=. # tests like [ -d ${variable} ] are true for variable not defined. [ -d "${variable}" ] are false. # same goes for -f and -e (I was getting some ugly output, wasn't sure were it came from, so I just correct the whole file) Hi Nelson Thanks for all your work. I will try it ... Just looked at the man page and saw the crypt_swap initrd option isn't in. This isn't your fault, but we might add it for completeness of the manual. Greetings Created attachment 127219 [details, diff]
genkernel_key_07.patch
Ok, added that to the man page. Also I didn't notice the initrd.defaults so I changed something I shouldn't have, sorry, now fixed.
Thanks Thomas, please test (I did so only on livecd's), and thanks for your work too.
Created attachment 128509 [details, diff]
genkernel_key_08.patch
ok, I tested this myself on hd by encrypting my swap, it didn't work because of lack of directories the livecd's have, now fixed.
Also added back swap keys since the previous case didn't allow root unencrypted w/ swap enc.
There's a non important message at reboot, I'll see if I can fix it.
Created attachment 128608 [details, diff]
genkernel_key_085.patch
Fixed it, easier than I thought. No issues that I see using encrypted swap.
Thank you Nelson for all your development. I will try your newest patch also, I guess I manage it this weekend. I'm not sure how you're doing it, it takes a few minutes, here's a script: cd svn co http://anonsvn.gentoo.org/repositories/genkernel wget http://bugs.gentoo.org/attachment.cgi?id=128608 patch -p0 < attachment.cgi?id=128608 su rm -rf /usr/share/genkernel svn export genkernel/trunk /usr/share/genkernel mount /boot for i in $(ls /boot/initramfs-genkernel*); do mv /boot/$i /boot/$i-safe;done genkernel --luks <more opts> initrd nano /boot/grub/grub.conf # remove root_keydev=... reboot #;) Created attachment 128927 [details, diff] genkernel_key_09.patch Small mistake, noticed while doing bug #189901, maybe you could test it too? :) Hi Nelson, I just tested your newest patch genkernel_key_09.patch The autodetection of the key_device works apparently, but with autodetection as well as with the key_device specified as parameter, I get a prompt to enter the LUKS key. I guess this is not intended, as the key should be read from the file. I'm sorry I got ATM no time for further investigations - the next week I'm abroad, but after I can help you with a more extended bug report. using: sys-fs/cryptsetup-luks-1.0.4-r3 sys-kernel/genkernel-3.4.9_pre1 And thanks a lot for all the work you did already! > sys-kernel/genkernel-3.4.9_pre1 You should try svn, in the revision mentioned on the patch, until I update it (if necessary). > The autodetection of the key_device works apparently, but with autodetection as > well as with the key_device specified as parameter, I get a prompt to enter the > LUKS key. That's odd. You mean the keyname or key value? In what situation does it ask for the key? Is it for the root or swap, or both? I have two computers with this (for swap), and it only asks for the key if something goes badly wrong (and I had to force these situations to test it, otherwise I don't need to insert anything). Ehh... 3.4.9_pre1 is identical to SVN currently. If it works against 3.4.9_pre1, I'll add it to SVN and roll up a newer pre-release for testing. I'm getting close to starting the next release cycle, so any testing/help you guys can get in now will allow for a longer testing cycle for the changes. > Ehh... 3.4.9_pre1 is identical to SVN currently. Yes, but not at the revision I used (not sure what you did after). Thing is, this works in my two pc's and in the bug #189901 (same cycle). Thomas said it worked but may've made some mistake as he didn't have much time. If you didn't modify the inits you can just merge now and label the keyfile functions as experimental (in the ebuild warning messages). This shouldn't break for users currently not using keyfiles and will allow greater user input. You can add the ebuild: ewarn "The LUKS keyfile functions are experimental. Please submit any bugs along with your bootloader config (such as grub.conf), /etc/fstab and removable media devices you have." ewarn "Make sure you have no other device with a file with the same location and name as your key, and your key devices support is built in the kernel." Well, this is going to be the last release (hopefully) for genkernel 3.4.x as I will be working on genkernel 3.5 after this, and we won't have a new genkernel for a *long* time after 3.4.9, so I am trying to get it in now. As for what is "experimental" or not, I consider everything in genkernel to be supported at the same level, whether I want to or not... :P If it doesn't work, it doesn't go in. If it goes in and is proven really broken, I'd remove it until it was fixed, rather than keep it in an experimental state. I simply prefer genkernel "work" for everyone or not support functions that sometimes work, or only work under certain circumstances. Ok, but without Thomas Bettler how do we know it's working? I'm almost going away for a semester, after that I may not be able to work here.
Anyway I think I know what happened to him.
Thomas:
> The autodetection of the key_device works apparently, but with autodetection as
> well as with the key_device specified as parameter, I get a prompt to enter the
> LUKS key.
Did you set the root_key? If you get the Luks prompt it's the only explanation (You see, it locates the keydev, but you still need to tell him the key name - that's how he recognizes it). Whenever you can, please share info asked on my previous comment.
Hi Nelson It was exactly that in the hurry I was, I forgot to change the bootparams from root_key back to swap_key. After this adoption it works really well, even autodetection, that's fantastic! I encourage the integration into new genkernel revision 3.4.9 PS: Thank you all for your work on LUKS integration. Comment on attachment 113106 [details, diff]
genkernel_3.4.6.patch
really obsolete now
What's the plan for integration in 3.4.9 - are these plans still alive? For many months I use the genkernel_key_09.patch from Nelson Batalha, which is working really fine! I'd be glad to see it integrated. I'm planning on adding it to 3.4.9, but with all the other changes we've made recently, it no longer applies to current SVN. I haven't had the time to spend to go through the patch and make it apply. The latest patch (with a few modifications due to changes in SVN) has been applied to SVN. This will be in the next release. This is fixed in 3.4.9_pre12, so please try it out and report back any problems. I was looking back at this patch for another bug, and I've got some concerns about one of the changes. In the findmediamount function (was findcdmount), you've got:
if [ -n "${CDROOT_DEV}" -a \( ${media}="cdrom" \) ]; then
mount -r -t auto ${x} ${NEW_ROOT}/mnt/cdrom >/dev/null 2>&1
else
mount -r -t auto ${x} ${mntdir} >/dev/null 2>&1
fi
That doesn't really make sense. What's the point of testing for $media = "cdrom" when you essentially run the same command for both of them? This should probably be:
if [ "${media}" = "cdrom" ]; then
mount -r -t iso9660 ${x} ${mntdir} &> /dev/null
else
mount -r -t auto ${x} ${mntdir} &> /dev/null
fi
This keeps the logic the same as it was previously (only using iso9660 for mounting a CD). Any objections?
agaffney: one of the reasons to not explicitly use iso9660, and use 'auto' instead, was apparent in some earlier genkernel versions, when copied directly to other media (such as a USB stick) - see the liveUSB howto, that is the liveCD just copied directly to a USB stick, with a some minor modifications to make syslinux happy (vs. isolinux). iirc, this also crops up if you burn the contents to a DVD as a pure UDF image instead of ISO9660 (or hybrid UDF/iso9660). Exactly what I was writing. I think I wanted the first line to be:
mount -r -t iso9660 ${x} ${mntdir} >/dev/null 2>&1
I'm sure I corrected that, and even searched to see if there was a need to do iso9660 instead of auto, and there was. Must've lost changes, sorry.
I made this change in SVN. Created attachment 139541 [details, diff]
correct latest svn changes
Sorry I believe it's actually worse now. It's broken for liveusb and now keyfile recognition is broken too since findmediamount now mounts only cd medias...
You'll find what you were looking for in the patch.
My fix was not "broken". Please explain how it breaks liveusb. I just condensed it down to a single mount statement. That -t auto is going to break the same way as it would for mounting the CD. We don't want it there by default. For booting a CD and using a USB key with vfat for the key, you'd want something like "cdroot_type=iso9660,vfat" or just "cdroot_type=auto". It's not "ideal", but it's the least likely to break. Created attachment 139545 [details, diff]
still small corrections
It's like Robin Johnson said. Ok, the liveusb howto could be changed to include cdroot_type=auto, and you could warn people about using udf.
'-t auto' was the default before my patch, like the two mount statements. If it's necessary to change that, add a new argument to findmediamount. Here:
Looking back through the commit history, it looks like the initramfs has been using -t auto for everything due to a logic error all the way since 2006-08-14. I'm better that this change wasn't in for 2006.1 (which is why people bitched about liveusb not working with 2006.1), but it was in for 2007.0 (I don't know if it works with this one). Anyway, my point is that it's apparently been -t auto for over a year, and I haven't seen any bugs relating to this. Perhaps this means that whatever the problem was with vfat many moons ago is now gone, and it's completely safe to use -t auto globally again. To be safe, we could do a global -t auto and reverse my previous change to override the -t auto with something of your choosing if you run into problems. (In reply to comment #37) > To be safe, we could do a global -t auto and > reverse my previous change to override the -t auto with something of your > choosing if you run into problems. This was placed in rev442 but now I can't find bugs that motivated this. If there are issues they must be in very special conditions, maybe wolf31o2 remembers? He said in #182818 : "we cannot use -t auto everywhere, for a reason. It causes lockups under some circumstances " So what do I need to do here? It looks like "-t auto" should be fine, globally, especially since that was the case before and it can still be overridden... Just switch the CDROOT_TYPE='iso9660' to auto in generic/initrd.defaults and that should be all that's needed. This should be resolved in genkernel 3.4.9, which will be hitting the tree shortly. If this is still an issue with that version, please REOPEN this bug (or comment, if you cannot REOPEN it). |
