With the support of the open-source community and a strict privilege system built into its architecture, Linux has security built into its design. That said, gone are the days when Linux system administrators could get away with poor security practices. Cybercriminals have come to view Linux as a viable attack target due to its growing popularity, the valuable devices it powers around the world, and a number of dangerous new Linux malware variants that have emerged in recent years.
It has become clear that most attacks on Linux systems can be attributed to misconfiguration and poor administration, and the lack of Linux kernel security is often at least partly to blame. Kernel security is a key determinant of overall system security, as the Linux kernel is the foundation of the Linux operating system and the primary interface between a computer’s hardware and its processes.
Fortunately, the Linux kernel has a range of built-in and effective security defenses—namely, firewalls that use kernel-integrated packet filters, Secure Boot, Linux Kernel Lockdown, and SELinux or AppArmor—that administrators should take full advantage of. This article will examine the importance of robust kernel security and explore several measures administrators can take to secure the Linux kernel and protect their systems from malware and other exploits.
How secure is the Linux kernel?
Kernel security is a constant concern for Linux system administrators, and securing the kernel is one of the most complex aspects of Linux system security. Even though the Linux kernel is under constant scrutiny for security bugs by the “many eyes” of the vibrant global open-source community, kernel vulnerabilities remain a persistent and serious threat. Flaws are inevitable in any operating system, and a large portion of Linux kernel bugs present potential security issues, often resulting in privilege escalation or denial-of-service (DoS) attacks. Critical kernel vulnerabilities can often be exploited by remote attackers, without any action required on the part of the victim. Some of the most well-known Linux kernel security flaws discovered and fixed in recent years are:
- CVE-2017-18017: This critical vulnerability, which resides in the netfilter tcpmss_mangle_packet function, is highly dangerous due to the central role it plays in filtering network communications by defining the maximum segment size allowed for accepting TCP headers. Without these controls, users are susceptible to overflow issues and DoS attacks. The flaw affects kernel versions prior to 4.11.
- CVE-2016-10229: This udp.c flaw, which also affects kernel versions prior to 4.5, allows a remote attacker to execute arbitrary code via UDP traffic, triggering a second insecure checksum during the execution of a recv system call with the MSG_PEEK flag.
- CVE-2016-10150: This use-after-free vulnerability, which affects kernel versions prior to 4.8.13, could be exploited by hackers to gain privileges and launch DoS attacks.
- CVE-2015-8812: This severe vulnerability affecting kernel versions prior to 4.5, discovered in Linux kernel drivers, allows a remote attacker to execute arbitrary code or cause a DoS (use-after-free) attack via crafted packets.
- CVE-2014-2523: This serious netfilter vulnerability, which affects kernel versions up to 3.13.6, is attributed to the incorrect use of a DCCP header pointer. The flaw allows a remote attacker to cause a DoS (system crash) attack or execute arbitrary code via a DCCP packet that triggers a call to the dccp_new, dccp_packet, or dccp_error function.
Tracking advisories is essential to protecting yourself from kernel vulnerabilities and keeping your system secure and up to date. Subscribing to our weekly Linux Advisory Watch newsletter is an easy and convenient way to stay up to date on the latest advisories and updates for your Linux distribution.
What is kernel self-protection and why is it important?
Linux kernel self-protection, or the design and implementation of systems and structures within the Linux kernel to protect against security flaws in the kernel itself, is an excellent way to add another layer of security to the Linux kernel. It includes defense methods such as reducing the attack surface, memory integrity, probabilistic defenses, and information exposure prevention. Let’s examine some tips and best practices for securing the Linux kernel by implementing these defense methods to protect your users, your systems, and your data.
Tips for Securing the Linux Kernel
Apply Kernel Security Patches
The Linux kernel is frequently patched to mitigate the latest security vulnerabilities that have been discovered, and while it may be monotonous, staying on top of kernel security updates is essential to maintaining a secure Linux system. The simplest method for updating the Linux kernel is to track your distribution’s security advisories and apply the latest available updates directly from your Linux distribution. There are three other methods for updating the kernel: at the command line, with kexec, or with a live kernel patching tool without rebooting. Updating the kernel from the command line is the method that is most likely covered in your distribution’s documentation. However, one of the main disadvantages of patching the kernel from the command line is that you will have to suffer the downtime of a system reboot. Administrators can speed up the reboot process by using the kexec system call. However, this method is risky, as it can cause data loss and corruption. The third method—updating the kernel automatically using a live kernel patching tool without rebooting, such as Livepatch, Ksplice, Kpatch, Kgraft, or KernelCare—is generally the method of choice for administrators, but it is not a substitute for full kernel updates, as it only applies patches for security vulnerabilities or critical bug fixes.
Enable Secure Boot in “Full” or “Thorough” Mode
UEFI Secure Boot is a verification mechanism to ensure that the code launched by a device’s UEFI firmware is trustworthy. The feature is designed to prevent malicious code from being loaded and executed before the operating system has been loaded. By enabling UEFI Secure Boot in “Full” or “Thorough” mode, administrators can reduce the attack surface on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Therefore, unsigned drivers for hardware cannot be loaded on systems with UEFI Secure Boot enabled in “full” or “thorough” mode. This makes it much more difficult for an attacker to insert a malicious kernel module into a system and for unsigned rootkits to remain persistent after reboot.
However, administrators should be aware that enabling Secure Boot comes with some potential drawbacks. For example, it requires manual intervention every time a kernel or module is updated. Using Secure Boot also enables “lockdown” mode, which disables several features that can be used to modify the kernel. We will cover this in more depth in the next section.
Learn more about UEFI Secure Boot and how to install a Linux system with Secure Boot enabled in this tutorial from Linux.org.
Use Linux kernel lockdown
Linux Kernel Lockdown is a kernel configuration option developed to provide a policy that prevents the root account from modifying kernel code, reinforcing the division between userland processes and kernel code. Thus, in the event that a root account is compromised, having Lockdown mode enabled will make it much more difficult for the compromised account to compromise the rest of the operating system. Although Lockdown was not introduced until the release of kernel version 5.4, work on this feature began more than a decade ago, led by Google engineer Matthew Garrett.
Lockdown support can be enabled with the kernel parameter lockdown=. The module has two modes: “integrity” mode and “confidentiality” mode. It is generally advisable to use “integrity” mode, and only use “confidentiality” mode for special systems that contain sensitive information that even root should not be able to see, such as the EVM signature key, which can be used to prevent offline file modification. Using confidentiality mode blocks access to all kernel memory, preventing administrators from inspecting and probing the kernel for purposes such as troubleshooting, development, and testing and verifying security measures. Setting lockdown=integrity will block kernel features that allow user space to modify the running kernel, while setting lockdown=confidentiality will block user space from extracting sensitive information from the running kernel. Administrators have the option to permanently apply integrity or confidentiality lockdown mode via SECURITY_LOCKDOWN_LSM_EARLY. All of these settings are controlled via the SECURITY_LOCKDOWN_LSM Kconfig option to enable the module.
Administrators should be aware that using Lockdown prevents several features and modules that can be used to modify the kernel from loading. For example, Lockdown disables:
- Loading kernel modules that are not signed by a trusted key, such as out-of-tree modules, including drivers managed by DKMS.
- Using kexec to boot an unsigned kernel image.
- Hibernation and resuming from hibernation.
- User space access to physical memory and I/O ports.
- Module parameters used to set memory addresses and I/O ports.
- Writing to MSRs via /dev/cpu/*/msr.
- Use of custom ACPI methods and tables.
- ACPI APEI error injection.
Enabling kernel module signing and loading rules
The Linux kernel supports digital signatures on loadable kernel modules, ensuring that only known and valid modules can be loaded and reducing the attack surface of a system with this requirement. Kernel module signing must be enabled in the kernel with the CONFIG_MODULE_SIG setting. Administrators can configure the kernel to require valid signatures, enable automatic module signing during the kernel build phase, and specify which hash algorithm to use. Local or remote keys can also be used.
In addition, limited module support can be enabled by default using the sysctl command kernel.modules_disabled=1. Sysctl is a way for administrators to communicate directly with the kernel to control its operation. These functions can also be configured in the /etc/sysctl.conf file. We explain how administrators can harden this file in the next section.
Disabling modules entirely can drastically reduce a system’s attack surface, but it is only practical in special use cases.
Hardening the Sysctl.conf File
The sysctl.conf file is the main point of configuration for kernel parameters for a Linux system. By using secure default values, your entire system will benefit from a more secure foundation.
With /etc/sysctl.conf, you can configure various network and Linux system parameters to improve security:
- Limiting network-transmitted configuration for IPv4
- Limiting network-transmitted configuration for IPv6
- Enabling execshield protection
- Protection against syn flood attacks
- Enabling source IP address verification
- Protecting a server’s IP address against spoofing attacks
- Logging suspicious packets such as fake packets, source-routed packets, and redirections
Learn how to harden the sysctl.conf file in this tutorial from nixCraft.
Enable SELinux or AppArmor
Modern Linux systems include the AppArmor or SELinux security enhancement systems (depending on the distribution) installed by default to protect against threats such as server misconfiguration, software vulnerabilities, and zero-day exploits, which could compromise an entire system without these controls. SELinux is installed and enabled by default on CentOS and RedHat Enterprise Linux operating systems, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems. These security enhancement systems allow granular access control with security policies, providing an additional layer of security throughout the system.
SELinux defines access controls for applications, processes, and files on a system, using security policies to enforce these access controls. When an application or process—known as a “subject”—makes a request to access an “object” such as a file, SELinux checks with an access vector cache (AVC), where permissions for subjects and objects are cached. If SELinux cannot make a decision about access based on the permissions stored in the cache, the request is forwarded to the security server, which checks the security context of the subject and object in the SELinux policy database. Permission is either granted or denied. If permission is denied, an “avc: denied” message will be available in /var/log.messages.
For typical use cases, we recommend that administrators configure SELinux in permissive mode. When operating in permissive mode, the policy is not enforced and the system remains operational. In other words, SELinux does not deny any operations, but only logs AVC messages, which administrators can use for troubleshooting, debugging AppArmor, and improving policies.
Like SELinux, AppArmor isolates applications and processes from each other with program profiles built into the kernel, as well as any profiles that an administrator has generated. AppArmor can be configured to enforce these profiles or to complain when profile rules are violated. AppArmor is less complex than SELinux, but in turn offers less control over how processes are isolated.
Unfortunately, it is quite common for administrators to disable SELinux or AppArmor when they encounter a problem, rather than learning how to solve the problem with these services enabled. This is poor administration and security practice, and can undermine a system’s overall security posture by leaving it susceptible to the very attacks that SELinux or AppArmor are designed to prevent.
Implement strict permissions
When all kernel memory is writable, it is easy for attacks to redirect the flow of execution, so it is imperative that kernel memory be protected with a strict set of permissions. Permissions should be as strict as is practical in a given environment.
Administrators should start by ensuring that executable code and read-only data are not writable. The CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX settings, which seek to ensure that code is not writable, data is not executable, and read-only data is neither writable nor executable, are the default options for most Linux architectures. In cases where these settings are user-selectable, an administrator can select ARCH_OPTIONAL_KERNEL_RWX to enable a Kconfig warning. CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT determines the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled.
It is essential that function pointers and sensitive variables, which are searched for by the kernel and used to continue execution, are read-only, not writable. Many of these variables can be made read-only by configuring them as “const” so that they reside in the .rodata section instead of the .data section of the kernel.
Permissions should always be configured to enforce the segregation of kernel memory from user space memory. These rules can be enforced through hardware-based restrictions or through emulation. By locking down user space memory, attacks are forced to operate entirely in kernel memory.
Use AuditD for continuous system monitoring
Careful monitoring of the Linux kernel allows administrators to discover security flaws, breaches, or policy violations, enabling them to mitigate the potential damage caused by these threats and verify the security of their systems. Using the Linux audit system (AuditD) is a popular and effective method for monitoring events occurring on a system. AuditD is a native feature of the Linux kernel, installed by default on most distributions and running automatically, which collects information about system activity, such as file permission changes, services being enabled or disabled, and network events, to facilitate the investigation of potential security incidents. It logs information according to its rules, as well as any custom rules added by the administrator. The kernel is the only one that can perform these functions because only it has direct access to all devices and thememoria del sistema.
This is an example of the type of information provided by the AuditD audit daemon. It shows users running specific commands such as /usr/bin/sudo and ssh generating a new session key.
type=USER_CMD msg=audit(1611763205.568:1621017): pid=1829220 uid=991 auid=4294967295 ses=4294967295 msg='cwd="/" cmd=2F7573722F6C6962363 exe="/usr/bin/sudo" terminal=? res=success'UID="nrpe" AUID="unset" type=CRYPTO_KEY_USER msg=audit(1611762843.231:1620894): pid=1825289 uid=0 auid=0 ses=49526 msg='op=destroy kind=server fp=SHA256:d7:c2:5a7 direction=? spid=1825289 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' UID="root" AUID="root" SUID="root"
This is an example of how “aureport” is used to generate a summary report of events that have occurred in the system.
[root@myhost ~]# aureport Summary Report ====================== Range of time in logs: 01/23/2021 04:54:03.379 - 01/27/2021 11:36:05.388 Selected time for report: 01/23/2021 04:54:03 - 01/27/2021 11:36:05.388 Number of changes in configuration: 67 Number of changes to accounts, groups, or roles: 0 Number of logins: 1457 Number of failed logins: 6249 Number of authentications: 1461 Number of failed authentications: 178 Number of users: 4 Number of terminals: 7 Number of host names: 661 Number of executables: 7 Number of commands: 1 Number of files: 0 Number of AVCs: 0 Number of MAC events: 65 Number of failed syscalls: 0 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 45395 Number of integrity events: 0 Number of virt events: 0 Number of keys: 0 Number of process IDs: 25064 Number of events: 136817 [root@myhost ~]# aureport -x --summary Executable Summary Report ================================= total file ================================= 71421 /usr/sbin/sshd 22796 /usr/sbin/crond 17905 /usr/lib/systemd/systemd 12344 /usr/bin/sudo 290 /usr/libexec/ipsec/pluto 26 /usr/bin/crontab 24 /usr/bin/su
To ensure optimal security and effectiveness, AuditD must be properly configured and hardened. Administrators should verify that the AuditD configuration is immutable using the “-e 2” control option and confirm that logs are stored in a centralized, secure location—ideally a server dedicated to accepting remote syslog events.
AuditD has some weaknesses that should be considered—namely, bugs, excessive overhead, lack of granularity, lack of container support, and onerous output.
Learn how to install and configure AuditD, create rules, and view the AuditD log in this tutorial from TechRepublic.
Key points
Linux is becoming an increasingly attractive target for cybercriminals due to its growing popularity and the high-value devices it powers around the world. Effective security depends on defense in depth, and kernel security is a key element of overall system security that cannot be overlooked. After all, the kernel is the foundation of a system, and if the kernel is not secure, then nothing in the system is secure. Therefore, it is vitally important that Linux system administrators prioritize kernel security and remain vigilant in implementing the tips and best practices discussed in this article to protect against security vulnerabilities and prevent exploits.
I hope you find this helpful.
