f8a9bc62 | 10-Sep-2019 |
Matthew Garrett <matthewgarrett@google.com> |
security: constify some arrays in lockdown LSM
No reason for these not to be const.
Signed-off-by: Matthew Garrett <mjg59@google.com> Suggested-by: David Howells <dhowells@redhat.com> Signed-off-by
security: constify some arrays in lockdown LSM
No reason for these not to be const.
Signed-off-by: Matthew Garrett <mjg59@google.com> Suggested-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
b602614a | 19-Aug-2019 |
Matthew Garrett <matthewgarrett@google.com> |
lockdown: Print current->comm in restriction messages
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
lockdown: Print current->comm in restriction messages
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: <comm>: <what> is restricted; see man kernel_lockdown.7
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
ccbd54ff | 19-Aug-2019 |
Matthew Garrett <matthewgarrett@google.com> |
tracefs: Restrict tracefs when the kernel is locked down
Tracefs may release more information about the kernel than desirable, so restrict it when the kernel is locked down in confidentiality mode b
tracefs: Restrict tracefs when the kernel is locked down
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 <mjg59@google.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
5496197f | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
debugfs: Restrict debugfs when the kernel is locked down
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 hard
debugfs: Restrict debugfs when the kernel is locked down
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 <dhowells@redhat.com> cc: Andy Shevchenko <andy.shevchenko@gmail.com> cc: acpi4asus-user@lists.sourceforge.net cc: platform-driver-x86@vger.kernel.org cc: Matthew Garrett <mjg59@srcf.ucam.org> cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg KH <greg@kroah.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Matthew Garrett <matthewgarrett@google.com> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
b0c8fdc7 | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
lockdown: Lock down perf when in confidentiality mode
Disallow the use of certain perf facilities that might allow userspace to access kernel data.
Signed-off-by: David Howells <dhowells@redhat.com
lockdown: Lock down perf when in confidentiality mode
Disallow the use of certain perf facilities that might allow userspace to access kernel data.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
9d1f8be5 | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
bpf: Restrict bpf when kernel lockdown is in confidentiality mode
bpf_read() and bpf_read_str() could potentially be abused to (eg) allow private keys in kernel memory to be leaked. Disable them if
bpf: Restrict bpf when kernel lockdown is in confidentiality mode
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 <alexei.starovoitov@gmail.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> cc: netdev@vger.kernel.org cc: Chun-Yi Lee <jlee@suse.com> cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
a94549dd | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
lockdown: Lock down tracing and perf kprobes when in confidentiality mode
Disallow the creation of perf and ftrace kprobes when the kernel is locked down in confidentiality mode by preventing their
lockdown: Lock down tracing and perf kprobes when in confidentiality mode
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 <alexei.starovoitov@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: davem@davemloft.net Cc: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
02e935bf | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
lockdown: Lock down /proc/kcore
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 p
lockdown: Lock down /proc/kcore
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 <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
906357f7 | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
x86/mmiotrace: Lock down the testmmiotrace module
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
x86/mmiotrace: Lock down the testmmiotrace module
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 <tglx@linutronix.de> Signed-off-by: David Howells <dhowells@redhat.com Signed-off-by: Matthew Garrett <mjg59@google.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Kees Cook <keescook@chromium.org> cc: Thomas Gleixner <tglx@linutronix.de> cc: Steven Rostedt <rostedt@goodmis.org> cc: Ingo Molnar <mingo@kernel.org> cc: "H. Peter Anvin" <hpa@zytor.com> cc: x86@kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
20657f66 | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
lockdown: Lock down module params that specify hardware parameters (eg. ioport)
Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs
lockdown: Lock down module params that specify hardware parameters (eg. ioport)
Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types).
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Jessica Yu <jeyu@kernel.org> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
794edf30 | 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
lockdown: Lock down TIOCSSERIAL
Lock down TIOCSSERIAL as that can be used to change the ioport and irq settings on a serial port. This only appears to be an issue for the serial drivers that use th
lockdown: Lock down TIOCSSERIAL
Lock down TIOCSSERIAL as that can be used to change the ioport and irq settings on a serial port. This only appears to be an issue for the serial drivers that use the core serial code. All other drivers seem to either ignore attempts to change port/irq or give an error.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
f474e148 | 19-Aug-2019 |
Matthew Garrett <mjg59@srcf.ucam.org> |
ACPI: Limit access to custom_method when the kernel is locked down
custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions o
ACPI: Limit access to custom_method when the kernel is locked down
custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> cc: linux-acpi@vger.kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
95f5e95f | 19-Aug-2019 |
Matthew Garrett <mjg59@srcf.ucam.org> |
x86/msr: Restrict MSR access when the kernel is locked down
Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Ba
x86/msr: Restrict MSR access when the kernel is locked down
Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook.
Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> cc: x86@kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
96c4f672 | 19-Aug-2019 |
Matthew Garrett <mjg59@srcf.ucam.org> |
x86: Lock down IO port access when the kernel is locked down
IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO
x86: Lock down IO port access when the kernel is locked down
IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default.
This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and KDDISABIO console ioctls.
Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> cc: x86@kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
eb627e17 | 19-Aug-2019 |
Matthew Garrett <mjg59@srcf.ucam.org> |
PCI: Lock down BAR access when the kernel is locked down
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel cod
PCI: Lock down BAR access when the kernel is locked down
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> cc: linux-pci@vger.kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|