lkml.org 
[lkml]   [2019]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PULL REQUEST] Lock down patches
From
Date
On 2/28/19 1:28 PM, 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.

Documentation/process/submitting-patches.rst says (IMO) that these
patches should also have Signed-of-by: <you>.

"The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path."

Also, the sysrq key usage should be documented in
Documentation/admin-guide/sysrq.rst.

> 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:
>
> 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.
>
> The following changes since commit a3b22b9f11d9fbc48b0291ea92259a5a810e9438:
>
> Linux 5.0-rc7 (2019-02-17 18:46:40 -0800)
>
> are available in the Git repository at:
>
> https://github.com/mjg59/linux lock_down
>
> for you to fetch changes up to 43e004ecae91bf9159b8e91cd1d613e58b8f63f8:
>
> lockdown: Print current->comm in restriction messages (2019-02-28
> 11:19:23 -0800)
>
> ----------------------------------------------------------------
> Dave Young (1):
> Copy secure_boot flag in boot params across kexec reboot
>
> David Howells (12):
> Add the ability to lock down access to the running kernel image
> Enforce module signatures if the kernel is locked down
> Prohibit PCMCIA CIS storage when the kernel is locked down
> Lock down TIOCSSERIAL
> Lock down module params that specify hardware parameters (eg. ioport)
> x86/mmiotrace: Lock down the testmmiotrace module
> Lock down /proc/kcore
> Lock down kprobes
> bpf: Restrict kernel image access functions when the kernel is locked down
> Lock down perf
> debugfs: Restrict debugfs when the kernel is locked down
> lockdown: Print current->comm in restriction messages
>
> Jiri Bohac (2):
> kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
> kexec_file: Restrict at runtime if the kernel is locked down
>
> Josh Boyer (2):
> hibernate: Disable when the kernel is locked down
> acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
>
> Kyle McMartin (1):
> Add a SysRq option to lift kernel lockdown
>
> Linn Crosetto (2):
> acpi: Disable ACPI table override if the kernel is locked down
> acpi: Disable APEI error injection if the kernel is locked down
>
> Matthew Garrett (7):
> Restrict /dev/{mem,kmem,port} when the kernel is locked down
> kexec_load: Disable at runtime if the kernel is locked down
> uswsusp: Disable when the kernel is locked down
> PCI: Lock down BAR access when the kernel is locked down
> x86: Lock down IO port access when the kernel is locked down
> x86/msr: Restrict MSR access when the kernel is locked down
> ACPI: Limit access to custom_method when the kernel is locked down
>
> arch/x86/Kconfig | 20 ++++++++++++-----
> arch/x86/include/asm/setup.h | 2 ++
> arch/x86/kernel/ioport.c | 6 ++++--
> arch/x86/kernel/kexec-bzimage64.c | 1 +
> arch/x86/kernel/msr.c | 10 +++++++++
> arch/x86/mm/testmmiotrace.c | 3 +++
> crypto/asymmetric_keys/verify_pefile.c | 4 +++-
> drivers/acpi/apei/einj.c | 3 +++
> drivers/acpi/custom_method.c | 3 +++
> drivers/acpi/osl.c | 2 +-
> drivers/acpi/tables.c | 5 +++++
> drivers/char/mem.c | 2 ++
> drivers/input/misc/uinput.c | 1 +
> drivers/pci/pci-sysfs.c | 9 ++++++++
> drivers/pci/proc.c | 9 +++++++-
> drivers/pci/syscall.c | 3 ++-
> drivers/pcmcia/cistpl.c | 3 +++
> drivers/tty/serial/serial_core.c | 6 ++++++
> drivers/tty/sysrq.c | 19 +++++++++++------
> fs/debugfs/file.c | 28 ++++++++++++++++++++++++
> fs/debugfs/inode.c | 30 ++++++++++++++++++++++++--
> fs/proc/kcore.c | 2 ++
> include/linux/ima.h | 6 ++++++
> include/linux/input.h | 5 +++++
> include/linux/kernel.h | 17 +++++++++++++++
> include/linux/kexec.h | 4 ++--
> include/linux/security.h | 9 +++++++-
> include/linux/sysrq.h | 8 ++++++-
> kernel/bpf/syscall.c | 3 +++
> kernel/debug/kdb/kdb_main.c | 2 +-
> kernel/events/core.c | 5 +++++
> kernel/kexec.c | 7 ++++++
> kernel/kexec_file.c | 56
> ++++++++++++++++++++++++++++++++++++++++++------
> kernel/kprobes.c | 3 +++
> kernel/module.c | 56
> ++++++++++++++++++++++++++++++++++++------------
> kernel/params.c | 26 ++++++++++++++++++-----
> kernel/power/hibernate.c | 2 +-
> kernel/power/user.c | 3 +++
> security/Kconfig | 24 +++++++++++++++++++++
> security/Makefile | 3 +++
> security/lock_down.c | 106
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 41 files changed, 466 insertions(+), 50 deletions(-)
> create mode 100644 security/lock_down.c
>


--
~Randy

\
 
 \ /
  Last update: 2019-03-01 00:25    [W:0.350 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site