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: <1551392438.10911.227.camel@linux.ibm.com>
Date:   Thu, 28 Feb 2019 17:20:38 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Matthew Garrett <mjg59@...gle.com>, jmorris@...ei.org
Cc:     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 13:28 -0800, Matthew Garrett wrote:
> Hi James,
> 
> David is low on cycles at the moment, so I'm taking over for this time
> round. This patchset introduces an optional kernel lockdown feature,
> intended to strengthen the boundary between UID 0 and the kernel. When
> enabled and active (by enabling the config option and passing the
> "lockdown" option on the kernel command line), various pieces of
> kernel functionality are restricted. Applications that rely on
> low-level access to either hardware or the kernel may cease working as
> a result - therefore this should not be enabled without appropriate
> evaluation beforehand.
> 
> The majority of mainstream distributions have been carrying variants
> of this patchset for many years now, so there's value in providing a
> unified upstream implementation to reduce the delta. This PR probably
> doesn't meet every distribution requirement, but gets us much closer
> to not requiring external patches.
> 
> 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?

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

Mimi