Lock It Up

The term lockdown does not have particularly positive connotations at present, but prior to COVID-19, the word was used in a very positive context as a term for air-tight security. Several months ago, Linux boss Linus Torvalds accepted a series of patches for the Linux kernel that introduced what is known as lockdown mode. Lockdown mode puts limits on the power of system users – including the once-all-powerful system administrator (root) account. Putting constraints on the root account might seem very strange to Unix/Linux veterans, but security experts are happy to see this powerful new feature in our dangerous times.

Long Time Ago

When Linus finally incorporated the lockdown patches into the official kernel at the end 2019, many observers described lockdown mode as a revolutionary new feature. But lockdown mode is not a new invention. In fact, the work on implementing the function took almost seven years. And for most of that time, the Linux kernel developers were arguing – sometimes heatedly – about the right way to do it (Figure 1). See the box entitled "Linux Security Modules" for more on a solution that arose from that heated debate.

Figure 1: Even in mid-2018, the developers were still debating fiercely about how to implement lockdown in a sensible way.

What's the Problem?

Which problem does the lockdown mechanism seek to solve? On a conventional Linux system, anyone with root privileges can do whatever they want. This means an attacker with sufficient privileges can change the core of the operating system and reload modules with new functionality. A highly sophisticated attacker can even replace central kernel features with their own versions of modules to deliberately cover their tracks.

Modern computers therefore try to defend themselves against this kind of attack on the firmware side. UEFI has a separate mechanism known as Secure Boot, which primarily affects the boot mode of the system. A system with active Secure Boot will only execute an OS boot loader if the boot loader has been digitally signed by a trusted party. The same applies to the kernel that this boot loader then starts. If Secure Boot is enabled, it also requires a digital signature. This is intended to create a chain of trust, thanks to which no malicious code ends up in the kernel.

The problem is, once an attacker gets past the boot loader, nothing in a conventional Linux system can prevent the loading of arbitrary modules. Even if the kernel is digitally signed, reloadable modules substantially weaken this security and the chain of trust breaks.

Lockdown mode can harden the kernel such that even the system user with the UID 0 is not allowed to change certain kernel structures.

Advanced LSM Features

To implement lockdown mode, the kernel developers had to expand the LSM stack. In its previous version, LSM was only designed to deal with problems once the userspace part (i.e., the environment that provides the kernel with policies) was active. However, an attacker could modify a system so that it loads malicious code immediately after start-up.

Part of the lockdown patch was therefore a new LSM module for early-stage security, which is loaded immediately after the kernel is started. At this time, the module has practically no kernel features available, and not even memory can be requested using malloc(). However, an end-to-end security strategy is in place. Once the early stage module is loaded, all necessary precautions at this time will take effect as specified by the administrator.

Using Lockdown Mode

To use lockdown mode, you need to call the lsm and lockdown parameters in the Linux kernel command line. The kernel command line (the command that actually starts the Linux kernel) is executed during the boot process – see your Linux distribution's documentation for more on adding Linux boot parameters. The lsm parameter activates the LSM subsystem and expects the lsm=lockdown,yama arguments for lockdown. If LSM is already activated for other modules, you just need to append lockdown and yama, separated by a comma, to the existing parameters. The lockdown parameter can have two arguments: integrity and confidentiality. I'll tell you more about lockdown's integrity and confidentiality modes later in this article.

In principle, lockdown mode can still be activated at run time by calling echo confidentiality or echo integrity with a redirect to the /sys/kernel/security/lockdown file. Of course, lockdown mode cannot be disabled at run time in either of these two scenarios. Enabling at run time is not quite as secure as enabling from the command line, because full protection does not kick in right from the first second (Figure 2).

Figure 2: Although you can enable lockdown mode while the system is running, this option is not as secure.

Integrity and Confidentiality

The developers offer two modes of the lockdown implementation. Integrity mode ensures that root cannot modify the currently running kernel. It implements what the developers originally wanted to achieve with the entire lockdown patch: that ability to establish the chain of trust between the running kernel and the originally started kernel.

In the meantime, however, lockdown mode has evolved. In addition to protecting the running system, the developers also focused on protecting any content that may currently be present in RAM. Root can access RAM and read it at will. This is precisely what confidentiality mode prevents. If confidentiality mode is active, the attempt to read memory will fail. Keeping users from reading memory significantly reduces the risk of passwords or other confidential data falling into the hands of attackers.

If you take a look at the Linux source code (Figure 3), you will see the concrete functions that the two lockdown modes trigger in the background. If the kernel is running in integrity mode, loading unsigned modules is prohibited. You can also no longer use kexec to make the system boot directly into a new kernel.

Figure 3: The Linux kernel's security.c file contains an overview of all functions that take effect when the lockdown kernel is activated.

Several modules in the Linux kernel offer functions that are explicitly marked as "insecure." In integrity mode, the kernel prevents root from using parameters that load such modules. If a user of the root account tries to use a parameter that loads an insecure module, the user will immediately see a Permission Denied response from the kernel. MMIO operations that are identified as insecure are also prevented by the kernel, as are certain ways of using perf. Another important fact: It is basically possible to modify the running kernel using a system's ACPI tables and thus compromise the kernel. This explains why integrity mode also deactivates these operations across the board. Also interesting for mobile systems: Lockdown mode deactivates the hibernation feature.

Confidentiality mode adds several additional constraints. Access to /dev/mem, /dev/kmem, and /dev/port is prevented by the kernel. Traffic on serial ports cannot be read by root. Access to debugfs for debugging purposes is disabled, as is access to /proc/kcore. Even with the Berkeley Packet Filter (BPF), you can no longer read kernel RAM directly.

Compatibility Problems

Lockdown mode disables various features that are used by userspace software. Many of the functions that lockdown mode disables are explicitly intended for debugging only but have existed for years or even decades. The fact that various userspace software tools have come to rely on these functions means that some applications might not work after you enable lockdown mode.

The kernel developers therefore view lockdown as an optional feature that is not enabled by default. If you want to use lockdown, plan some time and investigate whether your software works in the usual way after locking down. This is especially true for confidentiality mode. If confidentiality mode isn't right for your systems, you might still be able to use integrity mode, which prevents attackers from systematically opening up security holes.

Additional Safeguards

If you want to use lockdown mode, you need to monitor a few additional factors when operating your environment. After all, lockdown and any other security feature will not help if an attacker can disable them without being noticed.

Lockdown mode cannot prevent every possible security issue – for example, an admin can change certain files on the system. It is possible that a bad guy could quickly reconfigure GRUB to prevent lockdown mode from being activated in the first place.

Regular Checks

Discovering whether lockdown mode is still active is most easily done at the command line. During monitoring, you will want to check whether the lockdown parameter is defined in the /proc/cmdline file and whether it has a value of confidentiality or integrity. The LSM lockdown module also needs to appear in the kernel command line, otherwise the lockdown parameter has no effect.

Even without a lockdown mode in the kernel, all the alarms should go off if a system reboots unexpectedly. Most of the time, a sudden reboot is due to a broken hardware device or driver. But you need clarity about the root cause quickly. The problem could also be an attacker rebooting the system after changing the boot loader configuration. For this reason, I would recommend monitoring a few additional files of system config for example, /boot/grub/grub.cfg.

Do Not Feel Too Secure

Every admin should also be clear that absolute security does not exist. State-financed hackers usually spare no effort and are therefore capable of carrying out highly complex attacks. In fact, an attacker could simply overwrite the boot loader and use their own configuration file so that the grub.cfg stored on the system is not changed. You would only find out about this by checking if the currently running kernel is the one delivered by the manufacturer. If you want to secure your system against such attacks, you have a great deal of work to do. Lockdown mode in the Linux kernel is certainly not a carte blanche that lets you put your feet up and stop worrying about security.

This raises the question as to whether there are also things that Linux kernel lockdown mode does not protect systems against. The answer to this question is a resounding yes.

For example, lockdown does nothing at all to protect you against hardware-related errors. Prominent examples of hardware-based security flaws include the Spectre and Meltdown attacks that caused alarm throughout the Linux community a couple years ago. Although Spectre and Meltdown are now rendered harmless by other kernel workarounds, lockdown mode would not have been able to offer any protection against these bugs.

Similarly, the Linux kernel itself has unnoticed bugs that bypass lockdown mode. This was the case in June 2020, for example, when a bug in the ACPI code allowed kernel code to be smuggled past the UEFI Secure boot interface – and also past the lockdown module.

Conclusions

Lockdown mode is by no means just an abstract security feature that provides a little bit of extra security in special scenarios. After more than seven years, lead developer Matthew Garrett has succeeded in integrating a tangible feature into the Linux kernel that directly and immediately offers substantial improvements to the security of the system [1]. The fact that there was previously no way to prevent arbitrary kernel code from being loaded by root on Linux systems ultimately made nonsense of security campaigns based on components such as UEFI.

Lockdown mode makes it very clear to all administrators that the enemy does not necessarily come from outside. It's hard to believe that, in the year 2020, there are still security concepts that speak of secure internal and insecure external networks. Once an attacker has gained unauthorized root access to a system, almost all security measures are fatally ineffective. The kernel developers have skillfully put a stop to this in the form of a lockdown, which can only be removed by a malfunction in the kernel code.

Another important benefit is that lockdown mode is easy to use. A single parameter for the kernel command line is all it takes. But be careful: it is quite possible that some userspace software won't work with lockdown. Administrators need to test their systems with lockdown before beginning a comprehensive rollout (Figure 4).

Figure 4: Sorry, but no: If confidentiality mode is active, an attempt to read out the kernel RAM fails.

By the way, lockdown mode officially entered the kernel in Linux 5.4, which is now included with many desktop systems. Enterprise distributions, however, are a bit behind. At this writing, Ubuntu 20.04 LTS is the only enterprise distro that provides a sufficiently up-to-date kernel to use the official lockdown mode. On RHEL systems, the function is currently not available; however, Red Hat is expected to provide a patch in a future RHEL 8 release. SUSE is also planning to provide a patch.