All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: David Howells <dhowells@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Andy Lutomirski <luto@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Michal Marek <mmarek@suse.cz>,
	David Woodhouse <dwmw2@infradead.org>,
	Abelardo Ricart III <aricart@memnix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	keyrings@linux-nfs.org, Rusty Russell <rusty@rustcorp.com.au>,
	LSM List <linux-security-module@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>, Jiri Kosina <jkosina@suse.cz>
Subject: Re: Should we automatically generate a module signing key at all?
Date: Tue, 19 May 2015 13:32:00 -0400	[thread overview]
Message-ID: <1432056720.4510.143.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150519155532.GB2871@thunk.org>

On Tue, 2015-05-19 at 11:55 -0400, Theodore Ts'o wrote:
> On Tue, May 19, 2015 at 04:30:17PM +0100, David Howells wrote:
> > We do have to allow people to load external modules.  Yes, you could argue
> > that you should just disable all your security systems if you want to do
> > that...
> 
> Is module signing really meant for distro kernels, or would anyone
> besides people creating distro kernels care about this?  I thought I
> saw some messages (including from Linus) that the "common case" is the
> average kernel developer who creates a throw-away key, uses it to sign
> all of the modules in the kernel build, and then throws it away.
> 
> I wouldn't know, because I don't use module signing at all, and I
> don't really see the point.  I build my own kernels for my own use,
> which means either modules for my own developer convenience, or if I'm
> building it for a server where I really care about security, I'll
> build in exactly the drivers I need and disable modules entirely.  So
> I'm clearly not the intended use case, either as a distro kernel
> release engineer, or as a "build a kernel with modules and then throw
> away the key use case".
> 
> So I'm really curious --- are there significant numbers of people
> doing kernel builds, besides distro kernel engineers, who would use
> module signing?  If so, them sure, let's spend time optimizing so that
> it's really easy for those folks.  If not, maybe it's simpler just
> make things easy for people who will be storing the key in some
> external hardware device, and just be done with it.

I assume you're signing your kernel images.  Remember the Yubikey NEOs,
given out last year at the kernel summit, they can be used to sign the
kernel images and with David Woodhouse's patches sign the kernel modules
as well.

The next step (as mentioned in this thread), would be for software to
come signed.  The associated public key could be signed by the Yubikey
NEO and loaded onto the trusted IMA keyring.

Mimi


  parent reply	other threads:[~2015-05-19 17:33 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-18 16:04 Should we automatically generate a module signing key at all? David Howells
2015-05-18 16:19 ` David Woodhouse
2015-05-18 16:22   ` Linus Torvalds
2015-05-18 16:55     ` David Woodhouse
2015-05-18 16:20 ` Linus Torvalds
2015-05-19  0:51   ` Andy Lutomirski
2015-05-19  7:42     ` David Woodhouse
2015-05-19  8:53     ` David Howells
2015-05-19 12:46       ` David Woodhouse
2015-05-19 12:52         ` David Howells
2015-05-19 14:36       ` Andy Lutomirski
2015-05-19 15:30         ` David Howells
2015-05-19 15:55           ` Theodore Ts'o
2015-05-19 16:09             ` Petko Manolov
2015-05-19 16:23             ` David Howells
2015-05-19 17:55               ` Theodore Ts'o
2015-05-19 18:10                 ` David Howells
2015-05-19 21:47               ` Jiri Kosina
2015-05-20  7:45                 ` Michal Marek
2015-05-20  7:47               ` Michal Marek
2015-05-19 17:32             ` Mimi Zohar [this message]
2015-05-19 17:43               ` Andy Lutomirski
2015-05-19 17:53                 ` Linus Torvalds
2015-05-19 17:17           ` Andy Lutomirski
2015-05-19 18:38             ` David Howells
2015-05-19 18:46               ` Andy Lutomirski
2015-05-19 18:50                 ` David Howells
2015-05-19 18:57                 ` David Howells
2015-05-19 19:06                   ` Andy Lutomirski
2015-05-21 15:59                     ` David Howells
2015-05-19 15:37         ` Mimi Zohar
2015-05-19 15:53           ` Petko Manolov
2015-05-19 17:17           ` Andy Lutomirski
2015-05-19 17:44     ` Linus Torvalds
2015-05-19 17:58       ` Andy Lutomirski
2015-05-19 18:01         ` Linus Torvalds
2015-05-19 18:08         ` David Woodhouse
2015-05-19 18:12           ` Andy Lutomirski
2015-05-19 18:38             ` David Woodhouse
2015-05-19 18:49               ` Andy Lutomirski
2015-05-19 20:00                 ` David Woodhouse
2015-05-19 20:05                   ` Andy Lutomirski
2015-05-19 20:25                     ` David Woodhouse
2015-05-19 18:44             ` David Howells
2015-05-19 19:01               ` Andy Lutomirski
2015-05-21 16:10                 ` David Howells
2015-05-21 16:50                   ` Andy Lutomirski
2015-06-23 20:37       ` Pavel Machek
2015-05-20  5:01     ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2015-05-21 23:54 George Spelvin
2015-05-22  0:03 ` Linus Torvalds
2015-05-22  0:10   ` Andy Lutomirski
2015-05-22 14:13   ` George Spelvin
2015-05-22 20:40     ` Linus Torvalds
2015-05-22 20:44       ` Andy Lutomirski
2015-05-22 21:09         ` Linus Torvalds
2015-05-22 22:18           ` David Howells
2015-05-22 22:21             ` Linus Torvalds
2015-05-22 22:15       ` David Howells
2015-05-22 22:19         ` Andy Lutomirski
2015-05-22 22:21           ` David Howells
2015-05-22  0:03 ` Andy Lutomirski
2015-05-22 12:42   ` George Spelvin

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=1432056720.4510.143.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=aricart@memnix.com \
    --cc=bp@alien8.de \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=jkosina@suse.cz \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mmarek@suse.cz \
    --cc=rusty@rustcorp.com.au \
    --cc=sedat.dilek@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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.