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]
Date:	Mon, 18 May 2015 17:51:07 -0700
From:	Andy Lutomirski <luto@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>
CC:	Michal Marek <mmarek@...e.cz>,
	David Woodhouse <dwmw2@...radead.org>,
	Abelardo Ricart III <aricart@...nix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>, keyrings@...ux-nfs.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	LSM List <linux-security-module@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Should we automatically generate a module signing key at all?

On 05/18/2015 09:20 AM, Linus Torvalds wrote:
> On Mon, May 18, 2015 at 9:04 AM, David Howells <dhowells@...hat.com> wrote:
>>
>> Should we instead provide a script:
>>
>>          ./scripts/generate-key
>>
>> That generates a key if run and make it so that the build fails if you turn on
>> module signing and there's no key.
>
> That would just be stupid.
>
> I'm not ever applying a patch like that. That would absolutely destroy
> the sane "git clean + rebuild" model.
>
> Why the hell would you want to make the sane case that people actually
> *use* be harder to use.
>
> Nobody sane bothers with long-term keys. They are inconvenient and less secure.
>
> Put the onus on making it inconvenient on those people who actually
> have special keys, not on normal people.
>

I think we should get rid of the idea of automatically generated signing 
keys entirely.  Instead I think we should generate, at build time, a 
list of all the module hashes and link that into vmlinux.

If we want to make it better, we could instead have a concept of 
dynamically loadable module verifiers.  A module is acceptable if any of 
the verifiers approve.  We autogenerate module_hashes.ko, which 
registers a verifier that accepts the modules that were built by the 
kernel build in question.  The main vmlinux image includes another 
verifier that accepts *only* module_hashes.ko as built by the build in 
question.

Then, if anyone actually wants to use a public key to verify modules, 
they can build the public key into a module as opposed to dragging all 
of the public key crud into the main kernel image.

Also, this scheme is compatible with deterministic builds, whereas the 
current scheme is fundamentally broken if you try to deterministically 
build a kernel without trusting some key issuer.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ