public inbox for linux-integrity@vger.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: David Howells <dhowells@redhat.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	Ben Hutchings <ben@decadent.org.uk>
Subject: Re: linux-next: UEFI Secure boot lockdown patchset
Date: Tue, 01 May 2018 17:50:03 -0400	[thread overview]
Message-ID: <1525211403.5669.141.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJuuqYiSsaB9dhP9jYFx--y0VgnAWobswgViHamyMN5ijTg@mail.gmail.com>

On Tue, 2018-05-01 at 21:02 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 1:15 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > a) Requiring two signatures was addressed by a patch titled "lockdown:
> > fix coordination of kernel module signature verification" [1]
> 
> Ah, I'd missed that - thanks!
> 
> > There's been further discussions as to what should remain in the
> > "lockdown" patch set.  Based on the discussion here [2], it seems like
> >   "[PATCH 06/24] kexec_load: Disable at runtime if the kernel is locked
> > down" will be removed.
> 
> > Instead of preventing the loading of a kernel image (kexec_load
> >   syscall) being dependent on the lockdown flag, it could be dependent
> > on the kernel_read_file_id READING_KEXEC_IMAGE.  A version of these
> > patches was posted [3].
> 
> Hm. My concern is that distributions are going to ship IMA in a
> configuration that allows users to add their own keys at boot time (it's
> difficult to use it in a generic way otherwise), and that's going to allow
> kexecing of arbitrary images without requiring physical access. I think
> kexec_file_load() needs to be relying on non-IMA signatures.

I don't see how.  Unless the kernel was built with extra room for a
local CA public key (CONFIG_SYSTEM_EXTRA_CERTIFICATE), which would be
loaded onto the builtin keyring, there is no way of adding keys to the
IMA keyring.  Adding the extra public key would require the kernel to
be resigned.

Mimi

  reply	other threads:[~2018-05-01 21:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <26787.1519902415@warthog.procyon.org.uk>
2018-05-01 17:28 ` linux-next: UEFI Secure boot lockdown patchset Matthew Garrett
2018-05-01 19:00   ` David Howells
2018-05-01 20:15     ` Mimi Zohar
2018-05-01 21:02       ` Matthew Garrett
2018-05-01 21:50         ` Mimi Zohar [this message]
2018-05-01 21:59           ` Matthew Garrett
2018-05-01 22:21             ` Mimi Zohar
2018-05-01 22:32               ` Matthew Garrett
2018-05-01 23:43                 ` Mimi Zohar
2018-05-01 23:46                   ` Matthew Garrett
2018-05-02  1:00                     ` Mimi Zohar

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=1525211403.5669.141.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=ben@decadent.org.uk \
    --cc=dhowells@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=mjg59@google.com \
    /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