Re: [gentoo-hardened] Setting up a (more) secure notebook

[Marcel Meyer]

Thank you for dealing with my message :-)


Am Mittwoch, 18. November 2009 02:03:23 schrieb schism@×××××××××.org:
> FWIW, this doesn't *precisely* belong on -hardened, but since much of
> the audience for secured booting is the same I doubt many will complain.

Hehe, yes. And it's a hardened system (of course). And I have hardened 
compiler problems ;-). Aaand there was no traffic on gentoo-hardened for about 
a month. We have to check if the list is still working :-)



> On Wed, Nov 18, 2009 at 12:20:13AM +0100, Marcel Meyer wrote:
> > Now I'd like to try to use the usb-key just as a generic loader for an
> > already encrypted kernel on the harddrive. The kernel/initramfs of the
> > USB key loads the LUKS-partition and instead of booting this system with
> > the already loaded kernel from the USB key it should replace the running
> > kernel with another one incl. initramfs from the harddrive using kexec
> > from the encrypted partition.
>
> I'm following you all the way up to the kexec - what exactly are you
> trying to solve by doing that?

Well, several things.

First: convenience and reliability. By having a more or less static kernel and 
initramfs with a small, generic subset of modules which can boot all of my 
computers, I can reuse this USB stick (with several key/password-combinations) 
for more than one machine. And when updating the kernel and/or the modules on 
my "work-kernel" I don't have to remember adding it to the USB-stick and 
keeping it consistant. So updating because of the newest graphics card driver 
is a little less trouble.


> [..]
> If the kernel or initrd on the USB key are compromised (which it seems
> you're trying to protect against), they're under no obligation to follow
> the kexec path.  Once you've unlocked the LUKS partition the kimono has
> dropped, so to speak, and they're free to do whatever malicious deeds
> they wish.

Second: a little bit more security (by obscurity...?). You are right that a 
running kernel could do a lot of harm when having access to the data. But when 
that kernel on the USB stick decrypts a trustworthy kernel from the /boot on 
HD, calls kexec on it (the /sbin/init on this boot partition will have to do 
that) and this kernel then decrypts the /-partition with another password/key-
combination, shouldn't this help a little bit?

I mean I can not prevent this potential corrupted kernel from starting and 
then accessing my /boot partition. But as long as the "attacker" did not 
invest so much work to keep this kernel alive "behind" a kexec call or 
starting some virtual machine etc. pp., the newly started kernel should take 
full control - and if something different (like another kernel from the USB-
stick) is started, I will recognize that and don't enter the password for the 
data.

So my main question here is: does it make sense to replace the first kernel by 
a trusted second one or is it too easy to hide behind such functionality?


Of course this will not detain any serious hackers - besides they would have 
better methods like adding simple hardware hacks. But would this work as a 
protection against by-chance-hacker, getting somehow their hands on the key 
for a short time?




> Look at bug #204830 for a start on the TPM integration.  What's missing
> right now is an initrd-usable app (not all of TrouSerS) that would
> replace GPG in your use case, unsealing the key from the TPM and passing
> it on to cryptsetup.  I expect cryptsetup could be modified to do the
> job itself, but that's beyond my level of knowledge right now.

Thank you for that hint! I will follow it since at least my newest notebook 
now has some TPM chip inside.

I already searched for some USB tokens so that they can't be copied at least. 
But that still wouldn't help with the problem of a modified initramfs which 
sends stuff over the network, f.ex.


Thanks,
Marcel