All of lore.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 03:18:54 -0400	[thread overview]
Message-ID: <1430723934.5845.20.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.
>

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.

  parent reply	other threads:[~2015-05-04  7:19 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 [this message]
2015-05-04 21:40                     ` Abelardo Ricart III
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=1430723934.5845.20.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.