Re: Should we automatically generate a module signing key at all?

From: Andy Lutomirski
Date: Tue May 19 2015 - 15:07:02 EST


On Tue, May 19, 2015 at 11:57 AM, David Howells <dhowells@xxxxxxxxxx> wrote:
> Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>
>> Both Fedora and RHEL seems to be moving toward having fully-supported
>> configurations with immutable root images. Building those images
>> reproducibly would be fantastic. (Of course, if Fedora or RHEL wants
>> to allow support out-of-tree drivers, that's a different story.)
>
> Irrelevant. initramfs is *not* immutable. It has different modules in it
> depending on what hardware you have. Further, you *still* need the module and
> firmware hash lists in either the kernel or the initramfs to be loaded into
> kernel memory before you load the first module because you have to check the
> hash on it.

Well, that's a problem regardless of how module verification works,
and it'll probably need solving at some point. If the distro can't
sign initramfs, then you can get pwned by an attacker who modifies the
initramfs. ISTM whatever verifies the kernel image should maybe be
able to verify the initramfs as well. This might be tricky for distro
use cases, though.

Alternatively, we could eventually support some way of verifying a
hash or signature on each tuple (path, mode, contents) in the
initramfs image so that the only thing an attacker could do is replace
a valid initramfs with a different subset of the maximally complicated
initramfs. There may be an unavoidable configuration file or two in
there. In that case, distros should have the initramfs scripts be
reasonably resiliant to a maliciously configured initramfs.

If distros start using a TPM to protect access to the FS, they could
have the TPM verify the initramfs as well.

>
> Or are you suggesting a tree of hashed nodes that have leaves that are the
> hashes of the modules so you can save a subtree?
>

Yes, as in the email I just sent. (Actually, you never save a full
subtree -- it's implicit.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/