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 for Android: free password hash cracker in your pocket

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

Message-Id: <1551398720.10911.270.camel@linux.ibm.com>
Date:   Thu, 28 Feb 2019 19:05:20 -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 15:13 -0800, Matthew Garrett wrote:
> On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar <zohar@...ux.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.

I'm a little perplexed as to why you would send a pull request, before
re-posting the patches with the changes for review.

> 
> > >
> > > 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.  

Right, which is the reason the IMA architecture specific policy
requires file signatures. [1][2]

> 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

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]

> 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

Both the "CONFIG_IMA_APPRAISE_REQUIRE_KEXEC_SIGS" and the IMA
architecture policy rules persist after loading a custom policy.
 Neither of them require loading or signing a custom policy.

> 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.
> 

Having multiple signature verification methods is going to be around
for a while.  The solution is to coordinate the signature verification
methods, without requiring both types of signatures. [1][2]

[For distros that do enable IMA, enabling the IMA architecture
specific policy enforces the kexec kernel image and kernel modules
signature verification.]

Mimi

[1] Subject: [PATCH v2 0/5] selftests/ima: add kexec and kernel module tests
[2] Patches available from the "next-queued-testing" branch
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/