[V38,00/29] security: Add support for locking down the kernel

Message ID	20190808000721.124691-1-matthewgarrett@google.com (mailing list archive)
Headers	show Return-Path: <linux-security-module-owner@kernel.org> Date: Wed, 7 Aug 2019 17:06:52 -0700 Message-Id: <20190808000721.124691-1-matthewgarrett@google.com> Mime-Version: 1.0 Subject: [PATCH V38 00/29] security: Add support for locking down the kernel From: Matthew Garrett <matthewgarrett@google.com> To: jmorris@namei.org Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk
Series	security: Add support for locking down the kernel \| expand [V38,00/29] security: Add support for locking down the kernel [V38,01/29] security: Support early LSMs [V38,02/29] security: Add a "locked down" LSM hook [V38,03/29] security: Add a static lockdown policy LSM [V38,04/29] Enforce module signatures if the kernel is locked down [V38,05/29] Restrict /dev/{mem,kmem,port} when the kernel is locked down [V38,06/29] kexec_load: Disable at runtime if the kernel is locked down [V38,07/29] Copy secure_boot flag in boot params across kexec reboot [V38,08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE [V38,09/29] kexec_file: Restrict at runtime if the kernel is locked down [V38,10/29] hibernate: Disable when the kernel is locked down [V38,11/29] PCI: Lock down BAR access when the kernel is locked down [V38,12/29] x86: Lock down IO port access when the kernel is locked down [V38,13/29] x86/msr: Restrict MSR access when the kernel is locked down [V38,14/29] ACPI: Limit access to custom_method when the kernel is locked down [V38,15/29] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down [V38,16/29] acpi: Disable ACPI table override if the kernel is locked down [V38,17/29] Prohibit PCMCIA CIS storage when the kernel is locked down [V38,18/29] Lock down TIOCSSERIAL [V38,19/29] Lock down module params that specify hardware parameters (eg. ioport) [V38,20/29] x86/mmiotrace: Lock down the testmmiotrace module [V38,21/29] Lock down /proc/kcore [V38,22/29] Lock down tracing and perf kprobes when in confidentiality mode [V38,23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode [V38,24/29] Lock down perf when in confidentiality mode [V38,25/29] kexec: Allow kexec_file() with appropriate IMA policy when locked down [V38,26/29] debugfs: Restrict debugfs when the kernel is locked down [V38,27/29] tracefs: Restrict tracefs when the kernel is locked down [V38,28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down [V38,29/29] lockdown: Print current->comm in restriction messages

Message ID

20190808000721.124691-1-matthewgarrett@google.com (mailing list archive)

Headers

Date: Wed,  7 Aug 2019 17:06:52 -0700
Message-Id: <20190808000721.124691-1-matthewgarrett@google.com>
Mime-Version: 1.0
Subject: [PATCH V38 00/29] security: Add support for locking down the kernel
From: Matthew Garrett <matthewgarrett@google.com>
To: jmorris@namei.org
Cc: linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: owner-linux-security-module@vger.kernel.org
Precedence: bulk

Series

security: Add support for locking down the kernel | expand

Comments

James Morris Aug. 10, 2019, 6:08 a.m. UTC | #1

On Wed, 7 Aug 2019, Matthew Garrett wrote:

> Fixed an unused function parameter in patch 19, otherwise identical to
> V37.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-lockdown
and next-testing

Please verify and test, as I had to make a few minor fixups for my v5.2   
base.

Matthew Garrett Aug. 12, 2019, 5:06 p.m. UTC | #2

On Fri, Aug 9, 2019 at 11:08 PM James Morris <jmorris@namei.org> wrote:
> Please verify and test, as I had to make a few minor fixups for my v5.2
> base.

Thanks James - there's a few small fixups required, would you like
those as separate patches or should I just send you a fixed copy of
the original patchset?

James Morris Aug. 12, 2019, 5:39 p.m. UTC | #3

On Mon, 12 Aug 2019, Matthew Garrett wrote:

> On Fri, Aug 9, 2019 at 11:08 PM James Morris <jmorris@namei.org> wrote:
> > Please verify and test, as I had to make a few minor fixups for my v5.2
> > base.
> 
> Thanks James - there's a few small fixups required, would you like
> those as separate patches or should I just send you a fixed copy of
> the original patchset?

Given there are a few, an updated copy of the patchset will be best.

James Morris Aug. 12, 2019, 10:29 p.m. UTC | #4

On Tue, 13 Aug 2019, James Morris wrote:

> On Mon, 12 Aug 2019, Matthew Garrett wrote:
> 
> > On Fri, Aug 9, 2019 at 11:08 PM James Morris <jmorris@namei.org> wrote:
> > > Please verify and test, as I had to make a few minor fixups for my v5.2
> > > base.
> > 
> > Thanks James - there's a few small fixups required, would you like
> > those as separate patches or should I just send you a fixed copy of
> > the original patchset?
> 
> Given there are a few, an updated copy of the patchset will be best.

Actually, that's a lot of patches to resend, just send updates against my 
next-lockdown branch.