| Message ID | 20190306235913.6631-1-matthewgarrett@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PULL,REQUEST] Kernel lockdown patches for 5.2 | expand |
On Wed, 2019-03-06 at 15:58 -0800, Matthew Garrett wrote: > 3) The integration with IMA has been dropped for now. IMA is in the > process of adding support for architecture-specific policies that will > interact correctly with the lockdown feature, and a followup patch will > integrate that so we don't end up with an ordering dependency on the > merge The architecture specific policy is an attempt to coordinate between the different signature verification methods (eg. PE and IMA kexec kernel image signatures, appended and IMA kernel module signatures). The coordination between these signature verification methods is independent of the "lockdown" feature. To prevent requiring multiple signature verifications, an IMA policy rule(s) is defined only if either KEXEC_VERIFY_SIG or MODULE_SIG is not enabled. The kexec and kernel modules patches in this patch set continues to ignore IMA. This patch set should up front either provide an alternative solution to coordinate the different signature verification methods or rely on the architecture specific policy for that coordination. Mimi
On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > The kexec and kernel modules patches in this patch set continues to > ignore IMA. This patch set should up front either provide an > alternative solution to coordinate the different signature > verification methods or rely on the architecture specific policy for > that coordination. Hi Mimi, I'm working on a patch for this at the moment which can then be added to either patchset. Is there a tree that contains the proposed Power architecture policy? I want to make sure I don't accidentally end up depending on anything x86.
On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett <mjg59@google.com> wrote: > > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > The kexec and kernel modules patches in this patch set continues to > > ignore IMA. This patch set should up front either provide an > > alternative solution to coordinate the different signature > > verification methods or rely on the architecture specific policy for > > that coordination. > > Hi Mimi, > > I'm working on a patch for this at the moment which can then be added > to either patchset. Is there a tree that contains the proposed Power > architecture policy? I want to make sure I don't accidentally end up > depending on anything x86. I've been digging into this some more, and want to ensure that I get the appropriate semantics. Are we happy with the x86 solution for module signing (ie, if the arch policy is enabled and the kernel supports module signatures, use module signatures rather than IMA signatures)? If so, that just leaves kexec. For platforms that support PE signing for kernels (x86 and arm), are we ok punting to that? If so then to maintain the semantics we have for lockdown in general (ie, no way for a user to modify ring 0 code) then I think that would mean allowing kexec_file() only when the following criteria are met: 1) IMA is appraising kexec with digital signatures, either ima digital signatures or ima hashes with associated EVM digital signatures 2) CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an attacker being able to add a key to the keyring Does this sound reasonable? Are there any further criteria that are required for this?
On Mon, 2019-03-11 at 17:42 -0700, Matthew Garrett wrote: > On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett <mjg59@google.com> wrote: > > > > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > The kexec and kernel modules patches in this patch set continues to > > > ignore IMA. This patch set should up front either provide an > > > alternative solution to coordinate the different signature > > > verification methods or rely on the architecture specific policy for > > > that coordination. > > > > Hi Mimi, > > > > I'm working on a patch for this at the moment which can then be added > > to either patchset. Is there a tree that contains the proposed Power > > architecture policy? I want to make sure I don't accidentally end up > > depending on anything x86. > > I've been digging into this some more, and want to ensure that I get > the appropriate semantics. Are we happy with the x86 solution for > module signing (ie, if the arch policy is enabled and the kernel > supports module signatures, use module signatures rather than IMA > signatures)? There's a slight nuance you're missing. If the arch policy is enabled and the kernel supports module signatures, do not add an IMA appraise rule. A custom policy could require an IMA signature, as well as the module appended signature. Saying only use the module signatures, even if the IMA custom policy contains a kernel module rule, doesn't make sense. > If so, that just leaves kexec. For platforms that support > PE signing for kernels (x86 and arm), are we ok punting to that? Similarly, if the custom policy has a kexec kernel image policy rule, it shouldn't be ignored. > If so > then to maintain the semantics we have for lockdown in general (ie, no > way for a user to modify ring 0 code) then I think that would mean > allowing kexec_file() only when the following criteria are met: > > 1) IMA is appraising kexec with digital signatures, either ima digital > signatures or ima hashes with associated EVM digital signatures The kernel image could be signed with an appended signature as well. > 2) CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an > attacker being able to add a key to the keyring Agreed > Does this sound reasonable? Are there any further criteria that are > required for this? With the caveats described above. Mimi
Hi James, 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. 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. IMA is in the process of adding support for architecture-specific policies that will interact correctly with the lockdown feature, and a followup patch will integrate that so we don't end up with an ordering dependency on the merge The following changes since commit 468e91cecb3218afd684b8c422490dfebe0691bb: keys: fix missing __user in KEYCTL_PKEY_QUERY (2019-03-04 15:48:37 -0800) are available in the Git repository at: https://github.com/mjg59/linux lock_down for you to fetch changes up to 3d53449e0ac1df8cfdcc1ec48dc9cb622f220300: lockdown: Print current->comm in restriction messages (2019-03-06 13:32:19 -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/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 | 54 ++++++++++++++--- kernel/kprobes.c | 3 + kernel/module.c | 39 +++++++++--- 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 +++++++++++++++++++++++++++++++++ 40 files changed, 447 insertions(+), 44 deletions(-) create mode 100644 security/lock_down.c