From: Matthew Garrett <mjg59@google.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: jmorris@namei.org,
LSM List <linux-security-module@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>
Subject: Re: [PULL REQUEST] Lock down patches
Date: Thu, 28 Feb 2019 15:13:05 -0800 [thread overview]
Message-ID: <CACdnJuvwnh0PKr5jUTm2h=P5-u-oLgBjvThX+DxcegShXReCdA@mail.gmail.com> (raw)
In-Reply-To: <1551392438.10911.227.camel@linux.ibm.com>
On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Thu, 2019-02-28 at 13:28 -0800, Matthew Garrett wrote:
> > This PR is mostly the same as the previous attempt, but with the
> > following changes:
>
> Where/when was this latest version of the patches posted?
They should have followed this, but git-send-email choked on some
reviewed-by: lines so I'm just trying to sort that out.
> >
> > 1) The integration between EFI secure boot and the lockdown state has
> > been removed
> > 2) A new CONFIG_KERNEL_LOCK_DOWN_FORCE kconfig option has been added,
> > which will always enable lockdown regardless of the kernel command
> > line
> > 3) The integration with IMA has been dropped for now. Requiring the
> > use of the IMA secure boot policy when lockdown is enabled isn't
> > practical for most distributions at the moment, as there's still not a
> > great deal of infrastructure for shipping packages with appropriate
> > IMA signatures, and it makes it complicated for end users to manage
> > custom IMA policies.
>
> I'm all in favor of dropping the original attempt to coordinate
> between the kexec PE and IMA kernel image signatures and the kernel
> appended and IMA modules signatures, but there has been quite a bit of
> work recently coordinating the different types of signatures.
>
> Preventing systems which do use IMA for signature verification, should
> not limit their ability to enable "lock down". Does this version of
> the "lock down" patches coordinate the different kexec kernel image
> and kernel module signature verification methods?
It's a little more complicated than this. We can't just rely on IMA
appraisal - it has to be based on digital signatures, and the existing
patch only made that implicit by enabling the secure_boot policy. I
think we do want to integrate these, but there's a few things we need
to take into account:
1) An integrated solution can't depend on xattrs, both because of the
lagging support for distributing those signatures but also because we
need to support filesystems that don't support xattrs
2) An integrated solution can't depend on the current secure_boot
policy because that requires signed IMA policy updates, but
distributions have no way of knowing what IMA policy end users require
In any case, I do agree that we should aim to make this more
reasonable - having orthogonal signing code doesn't benefit anyone.
Once there's solid agreement on that we can extend this support.
next prev parent reply other threads:[~2019-02-28 23:15 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 21:28 [PULL REQUEST] Lock down patches Matthew Garrett
2019-02-28 22:20 ` Mimi Zohar
2019-02-28 23:13 ` Matthew Garrett [this message]
2019-03-01 0:05 ` Mimi Zohar
2019-03-01 1:01 ` Matthew Garrett
2019-03-01 1:44 ` Mimi Zohar
2019-03-01 3:33 ` Matthew Garrett
2019-03-01 4:16 ` Mimi Zohar
2019-02-28 22:44 ` [PATCH 01/27] Add the ability to lock down access to the running kernel image Matthew Garrett
2019-02-28 22:44 ` [PATCH 02/27] Add a SysRq option to lift kernel lockdown Matthew Garrett
2019-02-28 23:10 ` [PATCH 01/27] Add the ability to lock down access to the running kernel image Matthew Garrett
2019-02-28 23:10 ` [PATCH 02/27] Add a SysRq option to lift kernel lockdown Matthew Garrett
2019-02-28 23:11 ` [PATCH 01/27] Add the ability to lock down access to the running kernel image Matthew Garrett
2019-02-28 23:11 ` [PATCH 02/27] Add a SysRq option to lift kernel lockdown Matthew Garrett
2019-02-28 23:11 ` [PATCH 01/27] Add the ability to lock down access to the running kernel image Matthew Garrett
2019-02-28 23:11 ` [PATCH 02/27] Add a SysRq option to lift kernel lockdown Matthew Garrett
2019-02-28 23:11 ` [PATCH 03/27] Enforce module signatures if the kernel is locked down Matthew Garrett
2019-02-28 23:11 ` [PATCH 04/27] Restrict /dev/{mem,kmem,port} when " Matthew Garrett
2019-02-28 23:11 ` [PATCH 05/27] kexec_load: Disable at runtime if " Matthew Garrett
2019-02-28 23:11 ` [PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot Matthew Garrett
2019-02-28 23:11 ` [PATCH 07/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE Matthew Garrett
2019-02-28 23:11 ` [PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down Matthew Garrett
2019-03-01 2:05 ` Mimi Zohar
2019-02-28 23:11 ` [PATCH 09/27] hibernate: Disable when " Matthew Garrett
2019-03-19 22:15 ` Pavel Machek
2019-02-28 23:11 ` [PATCH 10/27] uswsusp: " Matthew Garrett
2019-02-28 23:11 ` [PATCH 11/27] PCI: Lock down BAR access " Matthew Garrett
2019-02-28 23:11 ` [PATCH 12/27] x86: Lock down IO port " Matthew Garrett
2019-02-28 23:11 ` [PATCH 13/27] x86/msr: Restrict MSR " Matthew Garrett
2019-02-28 23:11 ` [PATCH 14/27] ACPI: Limit access to custom_method " Matthew Garrett
2019-02-28 23:11 ` [PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been " Matthew Garrett
2019-02-28 23:11 ` [PATCH 16/27] acpi: Disable ACPI table override if the kernel is " Matthew Garrett
2019-02-28 23:11 ` [PATCH 17/27] acpi: Disable APEI error injection " Matthew Garrett
2019-02-28 23:11 ` [PATCH 18/27] Prohibit PCMCIA CIS storage when " Matthew Garrett
2019-02-28 23:11 ` [PATCH 19/27] Lock down TIOCSSERIAL Matthew Garrett
2019-02-28 23:11 ` [PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport) Matthew Garrett
2019-02-28 23:11 ` [PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module Matthew Garrett
2019-02-28 23:11 ` [PATCH 22/27] Lock down /proc/kcore Matthew Garrett
2019-02-28 23:11 ` [PATCH 23/27] Lock down kprobes Matthew Garrett
2019-02-28 23:12 ` [PATCH 24/27] bpf: Restrict kernel image access functions when the kernel is locked down Matthew Garrett
2019-02-28 23:12 ` [PATCH 25/27] Lock down perf Matthew Garrett
2019-02-28 23:12 ` [PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down Matthew Garrett
2019-02-28 23:12 ` [PATCH 27/27] lockdown: Print current->comm in restriction messages Matthew Garrett
2019-02-28 23:24 ` [PULL REQUEST] Lock down patches Randy Dunlap
2019-03-04 22:10 ` Matthew Garrett
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='CACdnJuvwnh0PKr5jUTm2h=P5-u-oLgBjvThX+DxcegShXReCdA@mail.gmail.com' \
--to=mjg59@google.com \
--cc=dhowells@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.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 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).