From: Mimi Zohar <zohar@linux.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: James Morris <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] Kernel lockdown patches for 5.2
Date: Mon, 11 Mar 2019 21:52:13 -0400 [thread overview]
Message-ID: <1552355533.24794.27.camel@linux.ibm.com> (raw)
In-Reply-To: <CACdnJuszfo4gTUD88p+8jeHU5e3hSdp+GEr8_=F1AMThPb7yWg@mail.gmail.com>
On Mon, 2019-03-11 at 17:42 -0700, Matthew Garrett wrote:
> On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett <mjg59@google.com> wrote:
> >
> > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > The kexec and kernel modules patches in this patch set continues to
> > > ignore IMA. This patch set should up front either provide an
> > > alternative solution to coordinate the different signature
> > > verification methods or rely on the architecture specific policy for
> > > that coordination.
> >
> > Hi Mimi,
> >
> > I'm working on a patch for this at the moment which can then be added
> > to either patchset. Is there a tree that contains the proposed Power
> > architecture policy? I want to make sure I don't accidentally end up
> > depending on anything x86.
>
> I've been digging into this some more, and want to ensure that I get
> the appropriate semantics. Are we happy with the x86 solution for
> module signing (ie, if the arch policy is enabled and the kernel
> supports module signatures, use module signatures rather than IMA
> signatures)?
There's a slight nuance you're missing. If the arch policy is enabled
and the kernel supports module signatures, do not add an IMA appraise
rule. A custom policy could require an IMA signature, as well as the
module appended signature.
Saying only use the module signatures, even if the IMA custom policy
contains a kernel module rule, doesn't make sense.
> If so, that just leaves kexec. For platforms that support
> PE signing for kernels (x86 and arm), are we ok punting to that?
Similarly, if the custom policy has a kexec kernel image policy rule,
it shouldn't be ignored.
> If so
> then to maintain the semantics we have for lockdown in general (ie, no
> way for a user to modify ring 0 code) then I think that would mean
> allowing kexec_file() only when the following criteria are met:
>
> 1) IMA is appraising kexec with digital signatures, either ima digital
> signatures or ima hashes with associated EVM digital signatures
The kernel image could be signed with an appended signature as well.
> 2) CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an
> attacker being able to add a key to the keyring
Agreed
> Does this sound reasonable? Are there any further criteria that are
> required for this?
With the caveats described above.
Mimi
next prev parent reply other threads:[~2019-03-12 1:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 23:58 [PULL REQUEST] Kernel lockdown patches for 5.2 Matthew Garrett
2019-03-06 23:58 ` [PATCH 01/27] Add the ability to lock down access to the running kernel image Matthew Garrett
2019-03-06 23:58 ` [PATCH 02/27] Add a SysRq option to lift kernel lockdown Matthew Garrett
2019-03-07 0:09 ` Randy Dunlap
2019-03-07 0:12 ` Matthew Garrett
2019-03-06 23:58 ` [PATCH 03/27] Enforce module signatures if the kernel is locked down Matthew Garrett
2019-03-08 23:00 ` James Morris
2019-03-08 23:30 ` Matthew Garrett
2019-03-09 4:45 ` James Morris
2019-03-06 23:58 ` [PATCH 04/27] Restrict /dev/{mem,kmem,port} when " Matthew Garrett
2019-03-06 23:58 ` [PATCH 05/27] kexec_load: Disable at runtime if " Matthew Garrett
2019-03-06 23:58 ` [PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot Matthew Garrett
2019-03-06 23:58 ` [PATCH 07/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE Matthew Garrett
2019-03-06 23:58 ` [PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down Matthew Garrett
2019-03-06 23:58 ` [PATCH 09/27] hibernate: Disable when " Matthew Garrett
2019-03-07 14:55 ` Alan Cox
2019-03-07 17:32 ` Matthew Garrett
2019-03-18 18:55 ` Alan Cox
2019-03-06 23:58 ` [PATCH 10/27] uswsusp: " Matthew Garrett
2019-03-06 23:58 ` [PATCH 11/27] PCI: Lock down BAR access " Matthew Garrett
2019-03-06 23:58 ` [PATCH 12/27] x86: Lock down IO port " Matthew Garrett
2019-03-06 23:58 ` [PATCH 13/27] x86/msr: Restrict MSR " Matthew Garrett
2019-03-06 23:59 ` [PATCH 14/27] ACPI: Limit access to custom_method " Matthew Garrett
2019-03-06 23:59 ` [PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been " Matthew Garrett
2019-03-06 23:59 ` [PATCH 16/27] acpi: Disable ACPI table override if the kernel is " Matthew Garrett
2019-03-06 23:59 ` [PATCH 17/27] acpi: Disable APEI error injection " Matthew Garrett
2019-03-06 23:59 ` [PATCH 18/27] Prohibit PCMCIA CIS storage when " Matthew Garrett
2019-03-06 23:59 ` [PATCH 19/27] Lock down TIOCSSERIAL Matthew Garrett
2019-03-06 23:59 ` [PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport) Matthew Garrett
2019-03-06 23:59 ` [PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module Matthew Garrett
2019-03-06 23:59 ` [PATCH 22/27] Lock down /proc/kcore Matthew Garrett
2019-03-06 23:59 ` [PATCH 23/27] Lock down kprobes Matthew Garrett
2019-03-06 23:59 ` [PATCH 24/27] bpf: Restrict kernel image access functions when the kernel is locked down Matthew Garrett
2019-03-06 23:59 ` [PATCH 25/27] Lock down perf Matthew Garrett
2019-03-06 23:59 ` [PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down Matthew Garrett
2019-04-25 10:49 ` Vasily Gorbik
2019-04-25 21:44 ` Matthew Garrett
2019-03-06 23:59 ` [PATCH 27/27] lockdown: Print current->comm in restriction messages Matthew Garrett
2019-03-07 3:56 ` [PULL REQUEST] Kernel lockdown patches for 5.2 Mimi Zohar
2019-03-07 4:24 ` Matthew Garrett
2019-03-12 0:42 ` Matthew Garrett
2019-03-12 1:52 ` Mimi Zohar [this message]
2019-03-07 15:59 ` [PATCH 02/27] Add a SysRq option to lift kernel lockdown David Howells
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=1552355533.24794.27.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=dhowells@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@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;
as well as URLs for NNTP newsgroup(s).