Bug 174294 - Patches to allow recognition of encrypted livecd, and location and use of key
|
Bug#:
174294
|
Product: Gentoo Hosted Projects
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P3
|
|
Resolution: FIXED
|
Assigned To: genkernel@gentoo.org
|
Reported By: nelson_batalha@hotmail.com
|
|
Component: genkernel
|
|
|
URL:
http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/
|
|
Summary: Patches to allow recognition of encrypted livecd, and location and use of key
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-04-12 16:10 0000
|
Cool.
I've added both to SVN and they'll show up in the next genkernel. I can't wait
to see the catalyst patch. ;]
(In reply to comment #1)
Thanks,
Now I'm having exams, but I promise to (hopefully) finish in August.
I would've done it already, but I had to learn python just for this.
Not really... it could be done all in bash. The only thing you'd have to do in
python is make it a valid value, which isn't that hard. Of course, now you
know python, so it's not like you wasted your time. ;]
File the catalyst patch (whenever you get to it) as a separate bug, please.
Oh no, this breaks the boot. (strange, I tested it at the time)
He complains that "/init:790 unterminated quoted string"... but doesn't seem
that simple. Busybox bug?
Have to study, revert or help?
So sorry!
ps.
For the record there's a lost "fi" (linuxrc line 593) and an extra "fi"
(initrd.scripts line 114), but that's not it.
Did the lost and extra "fi" come from your patches or were they already there?
Would you mind if I reverted this and we both looked at it together with Andrew
Gaffney to see if we can figure out what's going on? I'll keep it in for now,
and we'll revert it if wee need to do so.
I really like this idea and would love to see it integrated, along with the
capabilities from bug #162962 to also allow the key to reside on an external
location (floppy/usb key/etc) into a single working patch, even if we have to
do it in steps to get to that goal.
(In reply to comment #5)
It's probably better.
This will give me time to
#Allow it to boot a fake system if key not present/wrong ;).
#test luks vs. loop-aes performance and make the best choice
#change to use raw keys instead of "gpg" ones (best right?)
#change anything if necessary while doing the catalyst part ;).
(No, the error is my fault, previous linuxrc tested fine. I got confident and
did some changes just before posting :S).
Created an attachment (id=122988) [details]
problem fixed (boots ok now)
Ok, I'm guessing nobody tried luks on cd's, so I'll implement the LUKS linuxrc
to test/compare. Looks very easy, and that other bug/patch can also be applied
with no changes.
(All that is necessary is make sure startluks() is called later (for the cd),
and after doing LUKS_ROOT_KEY="$(head -n 1 ${NEW_ROOT}/mnt/cdrom/livecd)"
findkeymount() could set the LUKS_ROOT_KEYDEV, and then it's startluks).
Created an attachment (id=123127) [details]
Luks version, without keys. Extra boot option for added security
Please ignore last comments. Luks version tested, works great and code is much
simpler.
Added a new boot option "crypt_silent" that if set, will pretend not give away
the fact it's encrypted, and should be used in conjunction with keys: if
they're present it'll boot the system, if not it enters a shell quietly.
This I believe is great to security, there's a chance the person won't realize
encrypted data is there and will lose interest. It works for both livecd and hd
boot.
Anyone can start making livecd's in catalyst with this:
http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/catalyst_luks_hack_0.1.tar.gz
I integrated this last patch along with 3 others I did, and send them as a set
of git patches to wolf31o2.
convert to open with keyword=InSVN
Please test genkernel 3.4.9_prer1 or better. This should be fixed now.
(In reply to comment #6)
> This will give me time to
> #test luks vs. loop-aes performance and make the best choice
Performance or strength?
loop-aes is the strongest encryption available.
> #change to use raw keys instead of "gpg" ones (best right?)
Or smartcard :)
I will be happy to work with you on these... I tried to do this in current
genkernel init script but it made it very complex, so unless a major cleanup
will be applied, it would be very difficult to support all features (boot,
splash, resume, encryption, user dialog).
You can find an example from:
http://wiki.tuxonice.net/EncryptedSwapAndRoot
(In reply to comment #15)
> Performance or strength?
> loop-aes is the strongest encryption available.
Performance. Couldn't tell a difference, chose Luks since it was already
included.
> I will be happy to work with you on these... I tried to do this in current
> genkernel init script but it made it very complex, so unless a major cleanup
> will be applied, it would be very difficult to support all features (boot,
> splash, resume, encryption, user dialog).
Yes, indeed a major cleanup is required. See bug #189849, haven't reopened but
maybe will.
But other then that I think I finished this in the bug #162962. Splash works
since user dialog is unnecessary (if key is found). Still if something goes
wrong nothing happens, it should turn off splash then. I know nothing of resume
stuff, but the guy in that bug did something on that, which I kept in my patch.
> You can find an example from:
> http://wiki.tuxonice.net/EncryptedSwapAndRoot
>
So all left to implement is a code-cleanup, smartcards and splash_off if
decryption fails? Would you be interested in helping implement bug #189849?
After that it would be trivial to add loop-aes and gnupg support.
Cheers
