[V31,00/25] Add support for kernel lockdown

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

Message ID

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

Headers

Date: Tue, 26 Mar 2019 11:27:16 -0700
Message-Id: <20190326182742.16950-1-matthewgarrett@google.com>
Mime-Version: 1.0
Subject: [PATCH V31 00/25] Add support for kernel lockdown
From: Matthew Garrett <matthewgarrett@google.com>
To: jmorris@namei.org
Cc: linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org, dhowells@redhat.com,
        linux-api@vger.kernel.org, luto@kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: owner-linux-security-module@vger.kernel.org
Precedence: bulk

Series

Add support for kernel lockdown | expand

Message

Matthew Garrett March 26, 2019, 6:27 p.m. UTC

Updates: Based on Andy's feedback, lockdown is now a tristate and can be
made stricter at runtime. The states are "none", "integrity" and
"confidentiality". "none" results in no behavioural change, "integrity"
enables features that prevent untrusted code from being run in ring 0,
and "confidentiality" is a superset of "integrity" that also disables
features that may be used to extract secret information from the kernel
at runtime. I've also modified the bpf patch so that only the calls
documented as giving the ability to read in-kernel data are locked down,
rather than all functionality being disabled - I'm not a bpf expert so
would gladly go for further review here. Long term, it'd be preferable
to be able to tag secrets held by the kernel and grant access to
everything else, but I'm open to further feedback here. And at Greg's
request, debugfs is now largely disabled once the system is locked down.

In the general case, I'd expect distributions to opt for nothing
stricter than "integrity" - "confidentiality" seems more suitable for
more special-case scenarios.