Lockdown, the new adoption of the Linux kernel to limit root access to the kernel

The news recently broke that Linus Torvalds adopted a new component, which will be included in a future version of the "Linux 5.4" kernel. this new component has the name "Lockdown" which was proposed by David Howells (who has previously implemented this component in the Red Hat Kernel) and Matthew Garrett (Google developer).

The main function of lockdown is to limit the access of the root user to the system kernel and this functionality has been moved to the LSM module optionally loaded (Linux Security Module), which establishes a barrier between UID 0 and the kernel, limiting certain low-level functions.

This allows the lockout function to be policy-based rather than hard-coding an implicit policy within the mechanism, so the lock included in the Linux Security Module provides an implementation with a simple policy intended for general use. This policy provides a level of granularity controllable through the kernel command line.

This protection of access to the Nucleus is due to the fact that:

If an attacker succeeds in executing code with root privileges as a result of the attack, he can also execute his code at the kernel level, for example, replacing the kernel with kexec or reading and / or writing memory through / dev / kmem.

The most obvious consequence of this activity may be bypassing UEFI Secure Boot or recovering confidential data stored at the kernel level.

Initially, root restriction functions were developed in the context of strengthening verified boot protection and distributions have long been using third-party patches to block UEFI secure boot bypass.

At the same time, such constraints were not included in the core composition of the core due to disagreements in its implementation and fear of disruption of existing systems. The "lockdown" module incorporates patches already used in distributions, which were processed in the form of a separate subsystem that is not tied to UEFI Secure Boot.

When enabled, various pieces of kernel functionality are restricted. So applications that rely on low-level hardware or kernel access may stop working as a result, therefore this should not be enabled without proper evaluation beforehand. Linus Torvalds comments.

In lockdown mode, restrict access to / dev / mem, / dev / kmem, / dev / port, / proc / kcore, debugfs, debugfs, debugfs kprobes, mmiotrace, tracefs, BPF, PCMCIA CIS (card information secure), some ACPI and CPU MSR registers, kexec_file and kexec_load calls are blocked, sleep mode is prohibited, use of DMA for PCI devices is limited, import of ACPI code from EFI variables is prohibited, manipulations with ports I / O including changing the interrupt number and the I / O port for serial port are not allowed.

By default, the lockout module is not active; it is created when the SECURITY_LOCKDOWN_LSM option is specified in kconfig and it is activated by the kernel parameter "lockdown =", the control file "/ sys / kernel / security / lockdown" or the compilation options LOCK_DOWN_KERNEL_FORCE_ *, which can take the values of "integrity" and "confidentiality".

In the first case, the functions that allow changes to the working kernel from the user space are blocked, and in the second case, in addition to this, the functionality that can be used to extract confidential information from the kernel is disabled.

It is important to note that locking only limits the regular kernel access capabilities, but it does not protect against modifications as a result of exploiting vulnerabilities. To block changes to the working kernel when the Openwall project uses exploits, a separate LKRG (Linux Kernel Runtime Guard) module is being developed.

The lockdown function has had significant design reviews and comments on many subsystems. This code has been in Linux-next for a few weeks now, with a few fixes applied along the way.