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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrWF-ADeAE2Wwg_nv6RD4SZgiAgE0j5bH=qoHqnWqt=-pw@mail.gmail.com>
Date:	Tue, 19 May 2015 12:06:33 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Howells <dhowells@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	keyrings@...ux-nfs.org,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: Should we automatically generate a module signing key at all?

On Tue, May 19, 2015 at 11:57 AM, David Howells <dhowells@...hat.com> wrote:
> Andy Lutomirski <luto@...capital.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/