Bugzilla Bug 162962

Hi wolf31o2 (or whoever will look at my patch)

I wrote a patch to make the linuxrc and initrd.script, to add some features
- provide unencrypted keys for root / swap on any device (gpg not yet)
- resume from swsusp
- omit resuming (noresume param)


Therefore I introduced further parameters.

root_key: a file holding the key for the root partition (relative path)
swap_key:           ~ for the swap partition (relative path)
root_keydev: the device holding the unencrypted key for root 
                        (preferably removable one)
swap_keydev:            ~ for the swap partition

real_resume: any device to resume from (using swsusp)
noresume: skip resuming

Hope you like it. It works well for me, so I'd like to share it.
Greetings Thomas

Created an attachment (id=107569) [details]
genkernel-initrd_provide_luks_key.patch

The patch is against genkernel-3.4.6

Created an attachment (id=113106) [details]
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 an attachment (id=127069) [details]
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 an attachment (id=127219) [details]
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 an attachment (id=128509) [details]
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 an attachment (id=128608) [details]
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 an attachment (id=128927) [details]
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.

(From update of attachment 113106 [details])
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 an attachment (id=139541) [details]
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 an attachment (id=139545) [details]
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).