linux/security/lockdown, branch v5.4

efi/efi_test: Lock down /dev/efi_test and require CAP_SYS_ADMIN

2019-10-31T08:40:21Z

The driver exposes EFI runtime services to user-space through an IOCTL interface, calling the EFI services function pointers directly without using the efivar API. Disallow access to the /dev/efi_test character device when the kernel is locked down to prevent arbitrary user-space to call EFI runtime services. Also require CAP_SYS_ADMIN to open the chardev to prevent unprivileged users to call the EFI runtime services, instead of just relying on the chardev file mode bits for this. The main user of this driver is the fwts [0] tool that already checks if the effective user ID is 0 and fails otherwise. So this change shouldn't cause any regression to this tool. [0]: https://wiki.ubuntu.com/FirmwareTestSuite/Reference/uefivarinfo Signed-off-by: Javier Martinez Canillas Signed-off-by: Ard Biesheuvel Acked-by: Laszlo Ersek Acked-by: Matthew Garrett Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191029173755.27149-7-ardb@kernel.org Signed-off-by: Ingo Molnar

security: constify some arrays in lockdown LSM

2019-09-10T12:27:38Z

No reason for these not to be const. Signed-off-by: Matthew Garrett Suggested-by: David Howells Signed-off-by: James Morris

lockdown: Print current->comm in restriction messages

2019-08-20T04:54:17Z

Print the content of current->comm in messages generated by lockdown to indicate a restriction that was hit. This makes it a bit easier to find out what caused the message. The message now patterned something like: Lockdown: : is restricted; see man kernel_lockdown.7 Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Signed-off-by: James Morris

tracefs: Restrict tracefs when the kernel is locked down

2019-08-20T04:54:17Z

Tracefs may release more information about the kernel than desirable, so restrict it when the kernel is locked down in confidentiality mode by preventing open(). (Fixed by Ben Hutchings to avoid a null dereference in default_file_open()) Signed-off-by: Matthew Garrett Reviewed-by: Steven Rostedt (VMware) Cc: Ben Hutchings Signed-off-by: James Morris

debugfs: Restrict debugfs when the kernel is locked down

2019-08-20T04:54:17Z

Disallow opening of debugfs files that might be used to muck around when the kernel is locked down as various drivers give raw access to hardware through debugfs. Given the effort of auditing all 2000 or so files and manually fixing each one as necessary, I've chosen to apply a heuristic instead. The following changes are made: (1) chmod and chown are disallowed on debugfs objects (though the root dir can be modified by mount and remount, but I'm not worried about that). (2) When the kernel is locked down, only files with the following criteria are permitted to be opened: - The file must have mode 00444 - The file must not have ioctl methods - The file must not have mmap (3) When the kernel is locked down, files may only be opened for reading. Normal device interaction should be done through configfs, sysfs or a miscdev, not debugfs. Note that this makes it unnecessary to specifically lock down show_dsts(), show_devs() and show_call() in the asus-wmi driver. I would actually prefer to lock down all files by default and have the the files unlocked by the creator. This is tricky to manage correctly, though, as there are 19 creation functions and ~1600 call sites (some of them in loops scanning tables). Signed-off-by: David Howells cc: Andy Shevchenko cc: acpi4asus-user@lists.sourceforge.net cc: platform-driver-x86@vger.kernel.org cc: Matthew Garrett cc: Thomas Gleixner Cc: Greg KH Cc: Rafael J. Wysocki Signed-off-by: Matthew Garrett Signed-off-by: James Morris

lockdown: Lock down perf when in confidentiality mode

2019-08-20T04:54:16Z

Disallow the use of certain perf facilities that might allow userspace to access kernel data. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Signed-off-by: James Morris

bpf: Restrict bpf when kernel lockdown is in confidentiality mode

2019-08-20T04:54:16Z

bpf_read() and bpf_read_str() could potentially be abused to (eg) allow private keys in kernel memory to be leaked. Disable them if the kernel has been locked down in confidentiality mode. Suggested-by: Alexei Starovoitov Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook cc: netdev@vger.kernel.org cc: Chun-Yi Lee cc: Alexei Starovoitov Cc: Daniel Borkmann Signed-off-by: James Morris

lockdown: Lock down tracing and perf kprobes when in confidentiality mode

2019-08-20T04:54:16Z

Disallow the creation of perf and ftrace kprobes when the kernel is locked down in confidentiality mode by preventing their registration. This prevents kprobes from being used to access kernel memory to steal crypto data, but continues to allow the use of kprobes from signed modules. Reported-by: Alexei Starovoitov Signed-off-by: David Howells Signed-off-by: Matthew Garrett Acked-by: Masami Hiramatsu Reviewed-by: Kees Cook Cc: Naveen N. Rao Cc: Anil S Keshavamurthy Cc: davem@davemloft.net Cc: Masami Hiramatsu Signed-off-by: James Morris

lockdown: Lock down /proc/kcore

2019-08-20T04:54:16Z

Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. This is limited to lockdown confidentiality mode and is still permitted in integrity mode. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Signed-off-by: James Morris

x86/mmiotrace: Lock down the testmmiotrace module

2019-08-20T04:54:16Z

The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. This is a runtime check rather than buildtime in order to allow configurations where the same kernel may be run in both locked down or permissive modes depending on local policy. Suggested-by: Thomas Gleixner Signed-off-by: David Howells Acked-by: Steven Rostedt (VMware) Reviewed-by: Kees Cook cc: Thomas Gleixner cc: Steven Rostedt cc: Ingo Molnar cc: "H. Peter Anvin" cc: x86@kernel.org Signed-off-by: James Morris