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

On Wed, Nov 18, 2009 at 08:41:10PM +0100, Marcel Meyer wrote:
> 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.

I don't find that terribly convenient, but to each their own.  You're
building up a lot of complexity that's not going to necessarily be very
robust.

> 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?

Not really, once you have malicious code running on your machine at this
level, it's game over.  There are several approaches they can take to
getting your password, but if you've lost control of the first kernel
you've lost control of them all.

> 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.

I think you're both overestimating your powers of observation and
underestimating the abilities of an intentional and knowledgeable
attacker.  Anything can be faked.

> 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?

It doesn't really make sense because you're not protecting against a
"casual" attacker at this point anyway.  All FDE protects against is
powered-down physical compromise (typically theft or loss).  The moment
your threat model includes a malicious attacker returning ownership to
you, you've gone way beyond the "by-chance-hacker" assessment and deeply
into espionage territory.  At that point, if the attacker has had
manipulative access to your boot media, nothing short of hardware-level
measurements is really going to "guarantee" the safety of your data.  I
also refer you to http://xkcd.com/538/.

There's nothing stopping you from this pursuit, it simply isn't going to
protect against what you may think it does.  It adds unnecessary
complexity for that purpose, and complexity just adds more opportunities
for failure and subversion.  If you find it convenient, that's just up
to you.