Kernel Lockdown: Tightening Up Linux Kernel Access From User-Space
Red Hat developer David Howells has posted a series of patches to make it possible to lock-down the running Linux kernel image in an effort to prevent user-space from modifying the running kernel image.
This CONFIG_LOCK_DOWN_KERNEL option would tighten up what user-space can access/modify when running in this mode, likely paired to running under UEFI SecureBoot. Some of these restrictions in the kernel lockdown mode include no unsigned modules or modules that can't validate the signature, no use of ioperm/iopl() or writing to /dev/port, no writing to /dev/mem or /dev/kmem, no hibernation support, restricting PCI BAR and MSI access, no kexec_load(), some ACPI restrictions, and restricting debugfs access too. This would sharply tighten up what user-space can access/control when running in this mode.
In terms of running the kernel in this mode, Howells commented, "The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn't insecure. The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system."
The kernel lockdown patch series can be found here. As part of that is also these 38 separate patches where he's changing module parameter calls to make it clear if a kernel module parameter is configuring hardware resources. The kernel lockdown mode would also prohibit using these kernel module configuration parameters when in this tightened up mode.
This CONFIG_LOCK_DOWN_KERNEL option would tighten up what user-space can access/modify when running in this mode, likely paired to running under UEFI SecureBoot. Some of these restrictions in the kernel lockdown mode include no unsigned modules or modules that can't validate the signature, no use of ioperm/iopl() or writing to /dev/port, no writing to /dev/mem or /dev/kmem, no hibernation support, restricting PCI BAR and MSI access, no kexec_load(), some ACPI restrictions, and restricting debugfs access too. This would sharply tighten up what user-space can access/control when running in this mode.
In terms of running the kernel in this mode, Howells commented, "The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn't insecure. The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system."
The kernel lockdown patch series can be found here. As part of that is also these 38 separate patches where he's changing module parameter calls to make it clear if a kernel module parameter is configuring hardware resources. The kernel lockdown mode would also prohibit using these kernel module configuration parameters when in this tightened up mode.
15 Comments