linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: dhowells@redhat.com,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Vivek Goyal <vgoyal@redhat.com>,
	yannik@sembritzki.me, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Peter Anvin <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
	Justin Forbes <jforbes@redhat.com>,
	Peter Jones <pjones@redhat.com>,
	Matthew Garrett <mjg59@google.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot
Date: Thu, 16 Aug 2018 21:31:20 +0100	[thread overview]
Message-ID: <18926.1534451480@warthog.procyon.org.uk> (raw)
In-Reply-To: <1534435000.3166.9.camel@HansenPartnership.com>

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> As a step by step process, I agree.  However, I think we can automate
> it to the point where you install a package and it says "insert your
> yubikey" every time you upgrade the kernel

That's a very bad idea.  You train people to unlock their private key on
request.  It can be abused like one of those emails that tells you that your
account has been suspended - just follow the link and put in your password
please.

Further, you expose the unlocked key on a machine that might be compromised.

> Mehmet's patches don't require building a new kernel.  They merely
> require the added key be linked into the Red Hat built bzImage and then
> the resulting blob be signed.  You can still identify that the original
> bzImage is the Red Hat one.

No, you can't.  You might *think* that it is, but the signature you're
checking is after the image has being fiddled with by the key-adder - and that
means there's a window in which someone else can fiddle with the image too.

Mehmet's patches make sense from the reproducible kernel build PoV, but don't
actually help with the security so much since they're replacing, say, a RH
generated key with one you've generated locally, likely on the box that you
don't necessarily trust.

The bootloader would need to check the kernel image with the keys and the
image with the keys stripped off.  And if you're doing that, it doesn't make
sense to modify the kernel image, but rather load the keys separately,
possibly by an initrd=-like option on the bootloader or in your initrd.

> > That's the problem is right there.  AIUI, we *don't* want to set up a
> > third party signing process.  As I said, it potentially comes with lawyers
> > attached.
> 
> Right so generate a business pressure to overcome the legal one.

No.  We *really* don't want to do this, and the legal reasons are minor ones
like people suing us for GPL infringement[*] or because we said no.

The primary reason is that we aren't willing to just rubber stamp any old
kernel module.  The signature is, in effect, a certification.  We'd be putting
our name to something and we would want to be absolutely sure we know what it
does, review all the sources and have thoroughly tested it internally - and
we'd have to be willing to support it to some extent.  That takes a lot of
resources - and also requires the module vendor to be willing to open up their
sources to us.

We also don't want to sign the keys of third party vendors because then we
give away a certain degree of control over whatever they do with that, though
we would have the option of blacklisting it - after the fact.

[*] I've had people demand the transient private keys for Fedora kernels under
    the GPL.  They didn't seem to like the answer that I couldn't give them
    those keys because no one had them anymore; they seemed to think that this
    in some way violated their rights under the GPL.

David

  parent reply	other threads:[~2018-08-16 20:31 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 10:00 [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot Yannik Sembritzki
2018-08-15 16:54 ` Linus Torvalds
2018-08-15 17:27   ` Yannik Sembritzki
2018-08-15 17:37     ` Yannik Sembritzki
2018-08-15 17:42     ` Vivek Goyal
2018-08-15 18:44       ` Yannik Sembritzki
2018-08-15 18:58       ` Vivek Goyal
2018-08-15 19:06         ` Yannik Sembritzki
2018-08-15 19:49           ` Vivek Goyal
2018-08-15 20:47             ` Linus Torvalds
2018-08-15 20:53               ` James Bottomley
2018-08-15 21:08               ` Yannik Sembritzki
2018-08-15 21:13                 ` James Bottomley
2018-08-15 21:31                   ` Yannik Sembritzki
2018-08-15 21:40                     ` James Bottomley
2018-08-15 21:50                       ` Yannik Sembritzki
2018-08-15 21:57                     ` Vivek Goyal
2018-08-15 22:14                       ` Yannik Sembritzki
2018-08-15 21:52                   ` Vivek Goyal
2018-08-15 21:57                     ` James Bottomley
2018-08-15 21:14                 ` Linus Torvalds
2018-08-16 13:51             ` David Howells
2018-08-16 15:16               ` James Bottomley
2018-08-16 15:42                 ` James Bottomley
2018-08-16 15:49               ` David Howells
2018-08-16 15:56                 ` James Bottomley
2018-08-16 16:56                   ` David Laight
2018-08-16 17:15                     ` James Bottomley
2018-08-16 20:31                 ` David Howells [this message]
2018-08-17  0:07                   ` James Bottomley
2018-08-17  8:24                   ` David Howells
2018-08-17 14:58                     ` James Bottomley
2018-08-17 15:42                       ` Justin Forbes
2018-08-17 16:02                         ` James Bottomley
2018-08-16  0:52       ` Dave Young
2018-08-16  0:55         ` Dave Young
2018-08-16 12:13       ` David Howells
2018-08-16 14:22         ` James Bottomley
2018-08-16 14:43         ` David Howells
2018-08-16 14:59           ` James Bottomley
2018-08-17 17:00             ` Alan Cox
2018-08-15 17:45     ` Linus Torvalds
2018-08-15 18:19       ` Yannik Sembritzki
2018-08-15 18:22         ` Linus Torvalds
2018-08-15 19:42           ` [PATCH 0/2] Fix kexec forbidding kernels signed with keys in the secondary keyring " Yannik Sembritzki
2018-08-16 18:02             ` Linus Torvalds
2018-08-15 19:42           ` [PATCH 1/2] " Yannik Sembritzki
2018-08-15 19:42           ` [PATCH 2/2] Replace magic for trusting the secondary keyring with #define Yannik Sembritzki
2018-08-15 21:14             ` kbuild test robot
2018-08-15 21:19               ` [PATCH 2/2] [FIXED] " Yannik Sembritzki
2018-08-15 22:01                 ` Linus Torvalds
2018-08-15 22:07                   ` [PATCH 2/2] [FIXED v2] " Yannik Sembritzki
2018-08-16  1:11                     ` Dave Young
2018-08-16  7:43                       ` Yannik Sembritzki
2018-08-16  8:02                         ` Dave Young
2018-08-16  8:20                           ` Greg Kroah-Hartman
2018-08-16 12:46                       ` Vivek Goyal

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=18926.1534451480@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jforbes@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjg59@google.com \
    --cc=pjones@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --cc=yannik@sembritzki.me \
    /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;
as well as URLs for NNTP newsgroup(s).