From: Abelardo Ricart III <aricart@memnix.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Marek <mmarek@suse.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LSM List <linux-security-module@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>,
keyrings@linux-nfs.org, David Howells <dhowells@redhat.com>,
James Morris <james.l.morris@oracle.com>,
Sedat Dilek <sedat.dilek@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2]
Date: Mon, 04 May 2015 17:40:34 -0400 [thread overview]
Message-ID: <1430775634.5845.30.camel@memnix.com> (raw)
In-Reply-To: <CA+55aFzYUsXHC=_RiQFBhMmDxrFT4bqNP5F0LGWUu7Hc9sXBFQ@mail.gmail.com>
On Sun, 2015-05-03 at 22:16 -0700, Linus Torvalds wrote:
> On May 3, 2015 21:42, "Abelardo Ricart III" <aricart@memnix.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."
next prev parent reply other threads:[~2015-05-04 21:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 13:58 [PATCH] MODSIGN: Change default key details [ver #2] David Howells
2015-04-30 14:39 ` Sedat Dilek
2015-04-30 14:50 ` David Howells
2015-04-30 17:49 ` Sedat Dilek
2015-04-30 18:00 ` Linus Torvalds
2015-05-01 21:41 ` Abelardo Ricart III
2015-05-02 4:12 ` Linus Torvalds
2015-05-02 6:57 ` Sedat Dilek
2015-05-02 9:46 ` Abelardo Ricart III
2015-05-04 1:45 ` Linus Torvalds
2015-05-04 4:42 ` Abelardo Ricart III
[not found] ` <CA+55aFzYUsXHC=_RiQFBhMmDxrFT4bqNP5F0LGWUu7Hc9sXBFQ@mail.gmail.com>
2015-05-04 7:18 ` Abelardo Ricart III
2015-05-04 21:40 ` Abelardo Ricart III [this message]
2015-05-05 14:34 ` David Howells
2015-05-05 22:44 ` Abelardo Ricart III
2015-05-04 18:45 ` Linus Torvalds
2015-05-05 14:33 ` David Howells
2015-05-05 14:37 ` David Howells
2015-05-05 14:43 ` Linus Torvalds
2015-05-05 15:30 ` David Howells
2015-05-05 15:22 ` Michal Marek
2015-05-05 15:41 ` Linus Torvalds
2015-05-06 12:20 ` Michal Marek
2015-05-07 11:00 ` David Howells
2015-05-07 12:15 ` Michal Marek
2015-05-07 12:24 ` Michal Marek
2015-05-08 13:05 ` David Howells
2015-05-12 8:51 ` Michal Marek
2015-05-15 15:21 ` David Howells
2015-05-19 14:14 ` David Howells
2015-05-19 15:19 ` David Woodhouse
2015-05-18 16:07 ` David Woodhouse
2015-05-16 15:39 ` David Woodhouse
2015-05-18 10:47 ` David Howells
2015-05-18 10:56 ` David Howells
2015-05-18 11:13 ` David Woodhouse
2015-05-19 2:14 ` Mimi Zohar
2015-05-20 10:17 ` David Woodhouse
2015-05-20 10:51 ` David Howells
2015-05-20 11:08 ` David Woodhouse
2015-05-20 11:26 ` [PATCH] modsign: Use single PEM file for autogenerated key David Woodhouse
2015-05-20 14:56 ` David Howells
2015-05-20 15:18 ` David Woodhouse
2015-05-21 11:31 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430775634.5845.30.camel@memnix.com \
--to=aricart@memnix.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.l.morris@oracle.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=rusty@rustcorp.com.au \
--cc=sedat.dilek@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox