[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1430775634.5845.30.camel@memnix.com>
Date: Mon, 04 May 2015 17:40:34 -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.
> 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. 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
Here's a (barely tested) patch to show what I mean with the config option. The
default case is to always generate a new key at build (MODULE_SIG_BUILDGEN=y)
and fallback on generating keys during build only if one doesn't exist
(MODULE_SIG_BUILDGEN=n).
This fixes the issues with keys being unexpectedly overwritten when you don't
want them to be. Also fixes keys _not_ always being regenerated when they
really should be (the default use case).
---
diff --git a/init/Kconfig b/init/Kconfig
index dc24dec..5ab8b97 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1903,6 +1903,16 @@ config MODULE_SIG_ALL
comment "Do not forget to sign required modules with scripts/sign-file"
depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
+config MODULE_SIG_BUILDGEN
+ bool "Always generate keys during build"
+ default y
+ depends on MODULE_SIG
+ help
+ Always generate new signing keys at build time. Only say N here if
+ you intend on supplying your own signing keys.
+
+ Say Y here unless you know what you are doing.
+
choice
prompt "Which hash algorithm should modules be signed with?"
depends on MODULE_SIG
diff --git a/kernel/Makefile b/kernel/Makefile
index 60c302c..86d836d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -170,6 +170,15 @@ ifndef CONFIG_MODULE_SIG_HASH
$(error Could not determine digest type to use from kernel config)
endif
+.PHONY: generate_keys
+ifeq ($(CONFIG_MODULE_SIG_BUILDGEN),y)
+ # Always generate new signing keys
+ generate_keys: signing_key.priv signing_key.x509 FORCE
+else
+ # Only generate signing keys if they don't exist
+ generate_keys: | signing_key.priv signing_key.x509
+endif
+
signing_key.priv signing_key.x509: x509.genkey
@echo "###"
@echo "### Now generating an X.509 key pair to be used for signing modules."
--
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