linux-kernel - Re: [PULL REQUEST] Lock down patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1551413774.10911.308.camel@linux.ibm.com>
Date:   Thu, 28 Feb 2019 23:16:14 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     jmorris@...ei.org,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>
Subject: Re: [PULL REQUEST] Lock down patches

On Thu, 2019-02-28 at 19:33 -0800, Matthew Garrett wrote:
> On Thu, Feb 28, 2019 at 5:45 PM Mimi Zohar <zohar@...ux.ibm.com> wrote:
> >
> > On Thu, 2019-02-28 at 17:01 -0800, Matthew Garrett wrote:
> >
> > > > That's not a valid reason for preventing systems that do use IMA for
> > > > verifying the kexec kernel image signature or kernel module signatures
> > > > from enabling "lock down".  This just means that there needs to be
> > > > some coordination between the different signature verification
> > > > methods. [1][2]
> > >
> > > I agree, but the current form of the integration makes it impossible
> > > for anyone using an IMA-enabled kernel (but not using IMA) to do
> > > anything unless they have IMA signatures. It's a problem we need to
> > > solve, I just don't think it's a problem we need to solve before
> > > merging the patchset.
> >
> > That's simply not true.  Have you even looked at the IMA architecture
> > patches?
> 
> Sorry, I think we're talking at cross purposes - I was referring to
> your patch "ima: require secure_boot rules in lockdown mode"
> (https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=7fa3734bd31a4b3fe71358fcba8d4878e5005b7f).

With the "secure_boot" rules it was difficult to coordinate the
different signature verification methods.  Plus they weren't
persistent after loading a custom policy.

> If the goal is just to use the architecture rules then I don't see any
> conflict, 

yes

> and as far as I can tell things would just work as is if I
> drop the ima portion from "kexec_file: Restrict at runtime if the
> kernel is locked down"?

That code is a remnant left over from when the "secure_boot" policy
was enabled.  However, dropping the IMA portion there would result in
allowing only PE signed kernel images.  (On Power, for example, there
aren't any PE signatures.)

My suggestion would be to drop this patch and require the architecture
specific policy in "lock down" mode.

>  Apologies, I'd thought that the secure_boot
> ruleset was still intended to be used in a lockdown environment.

No, not any longer.

Mimi