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: <CA+55aFwBgeUeFK9HvjD3aX=p_Ad9zSvEVJtbC8NuHcOPrcMubA@mail.gmail.com>
Date:	Fri, 22 May 2015 14:09:12 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	George Spelvin <linux@...izon.com>,
	David Howells <dhowells@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	petkan@...-labs.com, "Theodore Ts'o" <tytso@....edu>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Subject: Re: Should we automatically generate a module signing key at all?

On Fri, May 22, 2015 at 1:44 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> In the threat model where module signatures matter in the first place
> [1], this prevents reproducible builds from serving their purpose.  I
> can build a kernel with a fresh signing key and throw away the private
> key.  You can build a canonically identical kernel with a private key
> that you keep.  A third party using mine is safe, but a third party
> using yours is unsafe, even though the whole packages canonicalize to
> exactly the same bytes.

So the thing is, I don't see why the third party couldn't just re-sign
his kernel with his own key (and throw it away).

Now he *is* safe. He can verify that the kernel and module images
match, and he has just guaranteed that no other modules can be loaded,
since module loading depends on *his* key.

So even if the silly case, I think signatures actually work fine.

And if he doesn't have access to all modules, then he wasn't safe with
the hash model anyway, because he'd have hashes in the kernel that he
couldn't validate.  So by definition, he'd have to have access to
everything he needs to just re-sign things.

And yes, he would need the ability to insert his own public key in the
kernel image (he already has the ability to re-sign the modules, we
have the script for that in the kernel build tree).

I still think that kind of "strip off and re-populate" the signatures
is a better model than having two completely different validation
models. I also suspect it's less work (although I do agree that it
likely means that we should package out certs differently).

But whatever. Code talks louder than words. If you have a good model
that does *not* screw up the build, and isn't too nasty, maybe we can
add that alongside signature verification.

                 Linus
--
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/