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>,
Nayna Jain <nayna@linux.vnet.ibm.com>
Subject: Re: linux-next: UEFI Secure boot lockdown patchset
Date: Tue, 01 May 2018 18:21:25 -0400 [thread overview]
Message-ID: <1525213285.5669.152.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJut41527gX5xh8em8i2sZhEwYno3hN37mhNqhk7Jmtb-9g@mail.gmail.com>
On Tue, 2018-05-01 at 21:59 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 2:50 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>
> > On Tue, 2018-05-01 at 21:02 +0000, Matthew Garrett wrote:
> > > 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.
>
> Oh, is kexec verified off the _module keyring? We still end up with the
> problem that distributions don't have a mechanism to ship IMA signatures
> yet, but that avoids the user modification problem. I've just posted a
> patchset to debian-dpkg, we'll see how that goes.
I'm not aware of a _module keyring. With IMA-appraisal, the signature
verification of the kernel image (kexec_file_load) uses the trusted
IMA keyring. Nayna Jain posted a patch that defines a new platform
keyring[1], which would only be used to validate the kernel image and
initramfs signatures.
Your review would be much appreciated!
I really do hope that some version of including file signatures in
Debian packages will be upstreamed soon. Good luck!
[1] https://lkml.org/lkml/2018/2/28/1089
Mimi
next prev parent reply other threads:[~2018-05-01 22:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 11:06 linux-next: UEFI Secure boot lockdown patchset David Howells
2018-03-01 11:06 ` David Howells
2018-03-01 11:08 ` Ard Biesheuvel
2018-03-01 11:08 ` Ard Biesheuvel
2018-03-01 11:24 ` David Howells
2018-03-01 11:24 ` David Howells
2018-03-01 12:15 ` Stephen Rothwell
2018-05-01 17:28 ` 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
2018-05-01 21:59 ` Matthew Garrett
2018-05-01 22:21 ` Mimi Zohar [this message]
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=1525213285.5669.152.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 \
--cc=nayna@linux.vnet.ibm.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 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.