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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.