Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
f22f9aaf |
| 17-Mar-2023 |
Paul Moore <paul@paul-moore.com> |
selinux: remove the runtime disable functionality
After working with the larger SELinux-based distros for several years, we're finally at a place where we can disable the SELinux runtime disable fun
selinux: remove the runtime disable functionality
After working with the larger SELinux-based distros for several years, we're finally at a place where we can disable the SELinux runtime disable functionality. The existing kernel deprecation notice explains the functionality and why we want to remove it:
The selinuxfs "disable" node allows SELinux to be disabled at runtime prior to a policy being loaded into the kernel. If disabled via this mechanism, SELinux will remain disabled until the system is rebooted.
The preferred method of disabling SELinux is via the "selinux=0" boot parameter, but the selinuxfs "disable" node was created to make it easier for systems with primitive bootloaders that did not allow for easy modification of the kernel command line. Unfortunately, allowing for SELinux to be disabled at runtime makes it difficult to secure the kernel's LSM hooks using the "__ro_after_init" feature.
It is that last sentence, mentioning the '__ro_after_init' hardening, which is the real motivation for this change, and if you look at the diffstat you'll see that the impact of this patch reaches across all the different LSMs, helping prevent tampering at the LSM hook level.
From a SELinux perspective, it is important to note that if you continue to disable SELinux via "/etc/selinux/config" it may appear that SELinux is disabled, but it is simply in an uninitialized state. If you load a policy with `load_policy -i`, you will see SELinux come alive just as if you had loaded the policy during early-boot.
It is also worth noting that the "/sys/fs/selinux/disable" file is always writable now, regardless of the Kconfig settings, but writing to the file has no effect on the system, other than to display an error on the console if a non-zero/true value is written.
Finally, in the several years where we have been working on deprecating this functionality, there has only been one instance of someone mentioning any user visible breakage. In this particular case it was an individual's kernel test system, and the workaround documented in the deprecation notice ("selinux=0" on the kernel command line) resolved the issue without problem.
Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
Revision tags: v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
1e7d8bcb |
| 08-Sep-2022 |
Nathan Lynch <nathanl@linux.ibm.com> |
lockdown: ratelimit denial messages
User space can flood the log with lockdown denial messages:
[ 662.555584] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.563237]
lockdown: ratelimit denial messages
User space can flood the log with lockdown denial messages:
[ 662.555584] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.563237] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.571134] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.578668] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.586021] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.593398] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7
Ratelimiting these shouldn't meaningfully degrade the quality of the information logged.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42 |
|
#
60cf7c5e |
| 14-May-2020 |
Jeremy Cline <jcline@redhat.com> |
lockdown: Allow unprivileged users to see lockdown status
A number of userspace tools, such as systemtap, need a way to see the current lockdown state so they can gracefully deal with the kernel bei
lockdown: Allow unprivileged users to see lockdown status
A number of userspace tools, such as systemtap, need a way to see the current lockdown state so they can gracefully deal with the kernel being locked down. The state is already exposed in /sys/kernel/security/lockdown, but is only readable by root. Adjust the permissions so unprivileged users can read the state.
Fixes: 000d388ed3bb ("security: Add a static lockdown policy LSM") Cc: Frank Ch. Eigler <fche@redhat.com> Signed-off-by: Jeremy Cline <jcline@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14 |
|
#
59438b46 |
| 27-Nov-2019 |
Stephen Smalley <sds@tycho.nsa.gov> |
security,lockdown,selinux: implement SELinux lockdown
Implement a SELinux hook for lockdown. If the lockdown module is also enabled, then a denial by the lockdown module will take precedence over S
security,lockdown,selinux: implement SELinux lockdown
Implement a SELinux hook for lockdown. If the lockdown module is also enabled, then a denial by the lockdown module will take precedence over SELinux, so SELinux can only further restrict lockdown decisions. The SELinux hook only distinguishes at the granularity of integrity versus confidentiality similar to the lockdown module, but includes the full lockdown reason as part of the audit record as a hint in diagnosing what triggered the denial. To support this auditing, move the lockdown_reasons[] string array from being private to the lockdown module to the security framework so that it can be used by the lsm audit code and so that it is always available even when the lockdown module is disabled.
Note that the SELinux implementation allows the integrity and confidentiality reasons to be controlled independently from one another. Thus, in an SELinux policy, one could allow operations that specify an integrity reason while blocking operations that specify a confidentiality reason. The SELinux hook implementation is stricter than the lockdown module in validating the provided reason value.
Sample AVC audit output from denials: avc: denied { integrity } for pid=3402 comm="fwupd" lockdown_reason="/dev/mem,kmem,port" scontext=system_u:system_r:fwupd_t:s0 tcontext=system_u:system_r:fwupd_t:s0 tclass=lockdown permissive=0
avc: denied { confidentiality } for pid=4628 comm="cp" lockdown_reason="/proc/kcore access" scontext=unconfined_u:unconfined_r:test_lockdown_integrity_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:test_lockdown_integrity_t:s0-s0:c0.c1023 tclass=lockdown permissive=0
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Reviewed-by: James Morris <jamorris@linux.microsoft.com> [PM: some merge fuzz do the the perf hooks] Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
Revision tags: v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9 |
|
#
359efcc2 |
| 29-Oct-2019 |
Javier Martinez Canillas <javierm@redhat.com> |
efi/efi_test: Lock down /dev/efi_test and require CAP_SYS_ADMIN
The driver exposes EFI runtime services to user-space through an IOCTL interface, calling the EFI services function pointers directly
efi/efi_test: Lock down /dev/efi_test and require CAP_SYS_ADMIN
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 <javierm@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Matthew Garrett <mjg59@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191029173755.27149-7-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
Revision tags: v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8 |
|
#
69393cb0 |
| 07-Sep-2019 |
Christopher M. Riedl <cmr@informatik.wtf> |
powerpc/xmon: Restrict when kernel is locked down
Xmon should be either fully or partially disabled depending on the kernel lockdown state.
Put xmon into read-only mode for lockdown=integrity and p
powerpc/xmon: Restrict when kernel is locked down
Xmon should be either fully or partially disabled depending on the kernel lockdown state.
Put xmon into read-only mode for lockdown=integrity and prevent user entry into xmon when lockdown=confidentiality. Xmon checks the lockdown state on every attempted entry:
(1) during early xmon'ing
(2) when triggered via sysrq
(3) when toggled via debugfs
(4) when triggered via a previously enabled breakpoint
The following lockdown state transitions are handled:
(1) lockdown=none -> lockdown=integrity set xmon read-only mode
(2) lockdown=none -> lockdown=confidentiality clear all breakpoints, set xmon read-only mode, prevent user re-entry into xmon
(3) lockdown=integrity -> lockdown=confidentiality clear all breakpoints, set xmon read-only mode, prevent user re-entry into xmon
Suggested-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190907061124.1947-3-cmr@informatik.wtf
show more ...
|
#
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 ...
|
Revision tags: v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
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 ...
|
#
3f19cad3 |
| 19-Aug-2019 |
David Howells <dhowells@redhat.com> |
lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down
Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down.
Suggested-by: Dominik Brodowski <l
lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down
Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down.
Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net> 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 ...
|
#
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 ...
|
#
38bd94b8 |
| 19-Aug-2019 |
Josh Boyer <jwboyer@fedoraproject.org> |
hibernate: Disable when the kernel is locked down
There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until
hibernate: Disable when the kernel is locked down
There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it when the kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.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: rjw@rjwysocki.net Cc: pavel@ucw.cz cc: linux-pm@vger.kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
#
7d31f460 |
| 19-Aug-2019 |
Matthew Garrett <mjg59@srcf.ucam.org> |
kexec_load: Disable at runtime if the kernel is locked down
The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prev
kexec_load: Disable at runtime if the kernel is locked down
The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prevent. It makes sense to disable kexec_load() in this situation.
This does not affect kexec_file_load() syscall which can check for a signature on the image to be booted.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Acked-by: Dave Young <dyoung@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> cc: kexec@lists.infradead.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
#
9b9d8dda |
| 19-Aug-2019 |
Matthew Garrett <mjg59@srcf.ucam.org> |
lockdown: Restrict /dev/{mem,kmem,port} when the kernel is locked down
Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loadin
lockdown: Restrict /dev/{mem,kmem,port} when the kernel is locked down
Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been locked down to prevent this.
Also disallow /dev/port from being opened to prevent raw ioport access and thus DMA from being used to accomplish the same thing.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: x86@kernel.org Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|