public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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."

  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