linux-kernel - Re: [PATCH] MODSIGN: Change default key details [ver #2]

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>] [day] [month] [year] [list]

Message-ID: <1430723934.5845.20.camel@memnix.com>
Date:	Mon, 04 May 2015 03:18:54 -0400
From:	Abelardo Ricart III <aricart@...nix.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Michal Marek <mmarek@...e.cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>, keyrings@...ux-nfs.org,
	David Howells <dhowells@...hat.com>,
	James Morris <james.l.morris@...cle.com>,
	Sedat Dilek <sedat.dilek@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2]

On Sun, 2015-05-03 at 22:16 -0700, Linus Torvalds wrote:
> On May 3, 2015 21:42, "Abelardo Ricart III" <aricart@...nix.com> wrote:
> >
> > That's correct. I was under the impression that having the Makefile generate
> > the signing keys was something that was done just to prevent a build failure
> > with CONFIG_MODULE_SIG but no keys.
> No, that's absolutely not the case.
> In fact, the whole "external keys" model is entirely bogus for any same use 
> case.
> The sane use case is to have the build process generate a random key at build
> time, that gets thrown away after installing the kernel and modules. That,
> together with "require signed modules" makes module as safe as building
> everything into the kernel - you won't be open to things like rootkits that
> try to load modules, because nobody has access to the key any more.
>

For varying degrees of accessibility. If the key gets overwritten with data
during removal that would be ideal.

> The only time you will have an external non-generated key is when you either
> want to do the insane secure boot thing, or when a distro builds an official
> kernel.

Or maybe signing and deploying a custom module for a very large amount of
machines that enforce module signing? Quite cumbersome when not utilizing your
own keys...

> But those are *not* the common development situations.
> So the "generated random throwaway key" is absolutely not some of special
> case to not break the build. It should be seen as the *default* case.
>    Linus

So one-time keys is the default case. What of the idea of a config option for
the other case as I'd proposed? One-time key generation being both the default
(always regenerate, sign, then throwaway. Overwrite existing keys and config.)
as well as the fallback (config option for one-time keys is unset, but external
keys are absent or invalid. Generate and use a new key pair as per usual).

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