| ccbd54ff | 20-Aug-2019 |
Matthew Garrett <[email protected]> |
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 <[email protected]> Reviewed-by: Steven Rostedt (VMware) <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: James Morris <[email protected]>
show more ...
|
| 5496197f | 20-Aug-2019 |
David Howells <[email protected]> |
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 <[email protected]> cc: Andy Shevchenko <[email protected]> cc: [email protected] cc: [email protected] cc: Matthew Garrett <[email protected]> cc: Thomas Gleixner <[email protected]> Cc: Greg KH <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: James Morris <[email protected]>
show more ...
|
| 20657f66 | 20-Aug-2019 |
David Howells <[email protected]> |
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 <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Jessica Yu <[email protected]> Signed-off-by: James Morris <[email protected]>
show more ...
|
| f474e148 | 20-Aug-2019 |
Matthew Garrett <[email protected]> |
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 <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
show more ...
|
| 95f5e95f | 20-Aug-2019 |
Matthew Garrett <[email protected]> |
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 <[email protected]> Signed-off-by: David Howells <[email protected]> Acked-by: Kees Cook <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
show more ...
|
| 96c4f672 | 20-Aug-2019 |
Matthew Garrett <[email protected]> |
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 <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
show more ...
|