Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
security advisorykey managementlinuxNSA: Managing Secure Boot for Linux Against Bootchain Attacks
The NSA’s recent guidance on UEFI Secure Boot reflects a shift that’s been building for years. Attackers have moved earlier in the boot process, while most defenses stayed focused higher up the stack. You start to see the gap once you follow a few incidents end-to-end. By the time the operating system loads, control has already been lost. Secure Boot sits at the boundary between hardware trust and software execution, squarely in the firmware security layer, and it only works when it’s treated as a required control rather than an optional hardening step. . Recent failures made that clear. Issues like BootHole, BlackLotus, and PKFail showed how permissive configurations, reused platform keys, and trusted but vulnerable bootloaders turn Secure Boot into an attack surface instead of a safeguard. For Linux security admins, this matters more than it’s often given credit for. Secure Boot is meant to enforce signature-based trust on firmware components, bootloaders, and kernels before disk encryption or monitoring tools ever run. When enforcement is weak or misconfigured, bootkits and deep persistence malware can survive reinstalls and remain invisible to user-space defenses, leaving systems that look clean but aren’t. Primer on UEFI Secure Boot Secure Boot is a UEFI feature designed to ensure that only trusted code runs during the earliest stages of system startup. Before the kernel loads, before initramfs, before any OS-level control can assert itself, firmware verifies that each component in the boot chain is signed by a key it trusts. If verification fails and enforcement is enabled, execution stops. That early decision point is the entire value of Secure Boot. Under the hood, this trust is managed through a small set of cryptographic stores maintained by the firmware: Platform Key (PK) establishes who controls Secure Boot on the system. If this key is missing or replaced with a test key, ownership of the boot policy is effectively open. Key Exchange Keys (KEK) are used toauthorize updates to the trusted and revoked databases. They’re how vendors and administrators rotate trust without resetting the platform. DB contains the allowed signing certificates and hashes for bootloaders, kernels, and other UEFI executables. DBX holds revoked signatures and hashes, blocking known-bad or vulnerable components even if they were once trusted. Secure Boot also operates in distinct modes that change how strictly these rules are enforced. In enforced mode, unsigned or untrusted code is rejected outright. In audit mode, violations are logged but allowed to run, which can create a false sense of safety if logs aren’t reviewed. Understanding these mechanics matters because most Secure Boot failures aren’t exploits. They’re configuration drift, outdated revocation lists, or keys that were never meant to ship in production but somehow did. Why Is Secure Boot Worth Managing? Secure Boot earns its keep by constraining what can run before the operating system has a chance to defend itself. That window is small, but it’s where attackers get the most leverage. Once malicious code executes in the boot chain, it can shape everything that comes after, including what the system reports about its own state. One of the clearest benefits is limiting boot-time compromise. Bootkits and other persistent malware target firmware and bootloaders specifically because they survive reinstallation and evade most endpoint tooling. Historical examples like BootHole and BlackLotus showed different paths to the same outcome. Control before the kernel means control without visibility. Without Secure Boot enforcing trust, attackers can insert code that runs before antivirus, integrity monitoring, or even disk encryption unlocks. There’s also a supply chain dimension that’s easy to underestimate. Secure Boot helps ensure that firmware and boot binaries haven’t been tampered with between manufacturing, imaging, and deployment. That doesn’t stop every malicious modification, butit raises the cost of inserting unauthorized code early in the lifecycle. It also gives administrators something concrete to measure, instead of assuming that what shipped is what’s running. Finally, Secure Boot operates independently of most OS-level controls. TPM-backed disk encryption, kernel hardening, and secure services all assume the boot path is trustworthy. They don’t enforce it. Secure Boot fills that gap by establishing trust before those controls exist, which is why disabling it to “simplify management” usually just shifts risk into a layer you can’t observe or audit later. Practical Tips for Linux Security Admins Managing Secure Boot Managing Secure Boot on Linux is less about flipping a switch and more about maintaining a known-good state over time. Most environments fail here through drift. A system gets imaged correctly, then firmware updates, hardware swaps, or emergency fixes quietly loosen the boot chain without anyone noticing. Start by verifying what’s actually enabled. On Linux systems, tools like mokutil and efivar can tell you whether Secure Boot is enforced and which variables are present. What matters isn’t just that Secure Boot says “enabled,” but that the Platform Key, KEKs, and DB and DBX contents match what you expect. Systems running in audit mode or missing revocation updates often look compliant at a glance and aren’t. You also have to look outside the operating system. Firmware setup screens still matter because legacy BIOS or compatibility support modules can bypass Secure Boot entirely. It’s common to find systems where Secure Boot is technically available but effectively unused due to permissive OEM defaults or leftover settings from initial provisioning. Understanding your bootloader chain is where Linux environments diverge. Most mainstream distributions implement Secure Boot using a signed shim binary that is trusted by firmware, which then verifies and launches GRUB2, which in turn loads a signed Linux kernel. For example, ona typical UEFI system you will find a Microsoft-signed shimx64.efi located at EFI/ /shimx64.efi in the EFI System Partition. This shim contains the distribution’s embedded certificate and is what allows Linux to boot on systems that trust Microsoft’s UEFI CA by default. Shim then verifies and hands off execution to grubx64.efi , which is signed by the distribution and located alongside shim in the EFI partition. GRUB2 is responsible for loading the kernel image—usually something like /boot/vmlinuz- —which itself must carry a valid cryptographic signature. If any one of these components is unsigned, signed with an untrusted key, or revoked via DBX, the boot process stops before the kernel ever runs. That chain only holds if each link is trusted and kept up to date. When administrators install custom kernels, rebuild GRUB, or load out-of-tree kernel modules, they often enroll a Machine Owner Key (MOK) so those components can be validated by shim at boot time. Once enrolled, that MOK becomes part of the system’s trust boundary whether it was formally documented or not, and its protection and lifecycle matter just as much as vendor-provided keys. As environments grow, ad hoc management stops working. Define a Secure Boot baseline that describes expected enforcement state, approved keys, and revocation levels. Capture hashes and certificates from known-good systems and compare them across your fleet. New hardware should be tested before deployment, not after an incident, to catch test keys or permissive defaults early. The Boot Process and Where Secure Boot Fits Boot Stage What Happens Where Secure Boot Applies Why This Stage Matters Power-on / Reset System firmware initializes CPU, memory, and hardware Secure Boot is not active yet Compromise here means firmware-level persistence UEFI Firmware Initialization Firmware loads drivers and prepares boot environment Secure Boot policy is enforced by firmware This is where trust enforcement begins Secure Boot Key Validation Firmware checks PK, KEK, DB, and DBX Core Secure Boot decision point Determines what code is allowed to execute Shim ( shimx64.efi ) First OS-controlled EFI binary loads Verified by firmware against DB Enables Linux to boot on systems trusting Microsoft UEFI CA GRUB2 ( grubx64.efi ) Bootloader presents menu and loads kernel Verified by shim Breaks if GRUB is unsigned or revoked Linux Kernel ( vmlinuz ) Kernel initializes system Verified by GRUB/shim Prevents unsigned kernels from executing Initramfs / Kernel Modules Early userspace and drivers load Optional signature enforcement Unsigned modules can weaken Secure Boot guarantees User Space Services and applications start Secure Boot no longer applies Security now depends on OS-level controls Automation helps here, but only if you’re clear on what you’re checking. Configuration management and auditing tools can report Secure Boot variables at scale, but someone still has to decide what “correct” looks like. In higher-risk environments, tightening trust stores and removing unused vendor keys can reduce exposure, at the cost of more careful update planning. That trade-off is usually worth understanding rather than avoiding. Practical Secure Boot Tools Linux Users Can Take With Them Tool What It Examines What It Tells You Why It Matters mokutil --sb-state Firmware Secure Boot state Whether Secure Boot is enabled and enforced A system can claim Secure Boot support while running in audit or disabled mode mokutil --list-enrolled Machine Owner Keys (MOKs) Which custom keys are trusted by shim Reveals undocumented trust added for custom kernels or modules mokutil --db, --dbx UEFI DB and DBX Trusted and revoked boot certificates Shows whether vulnerable boot components are still trusted efivar -l UEFI variables Full list of Secure Boot–related variables Helps identify missing, unexpected, or leftover keys sbverify --list EFI binaries Signature and signing certificate Confirms whether shim, GRUB, or kernels are actually signed pesign -S -i Signed binaries Signature validity and signer identity Useful for validating vendor or custom signatures lsblk -f / mount EFI EFI System Partition Location of shim and GRUB binaries Makes the boot chain tangible and inspectable Firmware setup UI Platform firmware Secure Boot mode, CSM/Legacy BIOS Prevents firmware-level bypasses that OS tools can’t detect Config management (Ansible, etc.) Fleet-wide state Secure Boot variable consistency Turns one-off checks into continuous assurance Configuration Challenges and How to Address Them Most Secure Boot failures aren’t dramatic. They come from small decisions made under time pressure, then forgotten. Over time, those decisions accumulate into a boot chain that looks enabled but no longer enforces much of anything. One common issue is Secure Boot being effectively disabled even when the firmware advertises support. Legacy BIOS modes , compatibility support modules, or permissive OEM defaults can all bypass enforcement. In some cases, systems ship with missing or placeholder keys, which means no one actually owns the trust policy. The fix usually starts with inventory. You can’t correct what you haven’t identified. Key and certificatetransitions introduce a different class of challenges. When Linux distributions or hardware vendors replace or rotate the cryptographic keys used to sign bootloaders and kernels, older signed components may no longer be trusted by the system firmware. At the same time, updates to the Secure Boot revocation list (the DBX) can explicitly block previously trusted but now vulnerable boot components. If DBX updates are delayed, systems may continue trusting known-exploitable bootloaders; if they are applied without proper preparation, systems may fail to boot. These issues most commonly surface during major distribution upgrades or vendor key rollovers, where trust relationships break silently and only become visible at the next reboot. Linux-specific signing workflows add friction as well: Custom kernels and third-party modules often require Machine Owner Key enrollment, expanding the trust boundary beyond vendor keys. Missed signatures don’t always fail immediately, especially if systems are running in audit mode. Different UEFI implementations expose Secure Boot controls and variables inconsistently, which complicates standardization across hardware models. The way through these challenges is boring but effective. Document expected key ownership. Track certificate lifetimes. Test updates and revocations before broad rollout. Secure Boot doesn’t fail because it’s fragile. It fails because it’s treated as static, when it actually needs the same lifecycle management as any other security control. Understanding the Everyday Impact on the Home Desktop User It’s easy to assume Secure Boot only matters in enterprise or government environments. For a single-user Linux desktop, the risk feels abstract, especially compared to phishing or browser exploits. That assumption holds until you look at where boot-level malware sits in the attack chain. Even a home system can be impacted when Secure Boot isn’t managed: Malware that infects the boot chain can persist across reinstallsand run before any user-space defenses initialize. Unsigned or malicious boot components from removable media or compromised updates can execute silently if no signature checks are enforced. A successful bootkit doesn’t need ongoing access. It only has to survive the next reboot to regain control. The practical risk for home users is lower and more targeted than for enterprises, but it isn’t zero. Enabling Secure Boot and keeping it correctly configured reduces the class of attacks that operate below the operating system, where visibility is limited, and recovery is harder. For individuals, that’s usually about preventing silent persistence rather than stopping commodity malware. Servers and Datacenter Impact Secure Boot matters more as systems become shared infrastructure. Servers concentrate data, credentials, and trust relationships, which makes early-stage compromise disproportionately valuable to an attacker. A single boot-level implant can undermine every workload that system hosts. Datacenter environments add complexity that desktops don’t. Hardware diversity is the norm, not the exception, and UEFI implementations vary widely across vendors and generations. Without a defined baseline, it’s easy for clusters to drift into mixed Secure Boot states where enforcement is inconsistent and hard to reason about. Operationally, Secure Boot needs to be part of provisioning, not a post-build check: New systems should be validated for enforcement state, key ownership, and revocation levels before they join a cluster. Secure Boot expectations should be enforced uniformly across nodes to avoid weak points in otherwise hardened environments. Build and provisioning pipelines are a natural place to include these checks, because that’s where trust is first established. In server contexts, the cost of managing Secure Boot is usually lower than the cost of investigating a compromise that never touches the operating system. Once firmware-level trust is lost, everythingabove it becomes suspect, and that’s not a position most teams want to debug from. Cloud and Virtualization Considerations Secure Boot looks different once hardware is abstracted, but the underlying trust problem doesn’t go away. In cloud and virtualized environments, firmware is often virtual firmware, and enforcement depends on what the hypervisor exposes to the guest. Public cloud providers typically offer UEFI Secure Boot as an optional feature for virtual machines. When enabled, the guest firmware enforces signature checks in much the same way physical systems do. When it’s disabled, the VM boots whatever the hypervisor allows, and the trust boundary shifts upward without much visibility. For workloads with compliance or isolation requirements , that distinction matters. There are a few patterns worth paying attention to: Traditional Secure Boot on physical hardware doesn’t automatically apply to virtual machines unless the hypervisor exposes UEFI Secure Boot to guests. Many providers support Secure Boot–style enforcement in guest firmware settings, which is easy to miss during instance creation. Some virtualization stacks, including KVM-based environments, allow Secure Boot policies to be passed through or enforced at the virtual firmware layer. The takeaway is that firmware security still exists in the cloud. It’s just mediated by the platform. If Secure Boot is part of your baseline on bare metal, the equivalent control should be evaluated and enabled for virtual workloads, otherwise you’re accepting a weaker trust model without necessarily meaning to. Broader Operational Takeaways for Managing & Configuring Secure Boot Secure Boot is a foundational control for boot integrity, but only when it’s actively managed. Defaults are rarely sufficient because they assume clean keys, consistent updates, and no drift over time. In practice, systems get patched unevenly, firmware gets replaced, revocation lists lag, and trust stores quietly expand. Avoiding thatpitfall means treating Secure Boot like any other security control. Verify enforcement, own the keys, track revocations, and revisit the configuration as systems change. Regular auditing and baseline enforcement matter more than the initial setup. This applies to fleets, servers, and even single machines where persistence below the OS would be costly to unwind. Boot-level threats are quiet by design, and firmware security is one of the few places you can still stop them early. The NSA guidance is useful because it reinforces that reality. Secure Boot isn’t a checkbox. It’s part of ongoing system hygiene, and it belongs in day-to-day security operations. . Learn how to defend Linux systems from bootchain attacks with NSA's guidance on managing Secure Boot effectively.. Linux Secure Boot, bootchain security, persistent malware, firmware security, UEFI management. . Brittany Day
Dec 31, 2025
•
102
security practiceskernel securitysystem hardeningEssential Guide for Securing the Linux Kernel Environment Effectively
With the support of the open-source community and a strict privilege system embedded in its architecture, Linux has security built into its design. That being said, gone are the days when Linux system administrators could get away with subpar security practices. Cybercriminals have come to view Linux as a viable attack target due to its growing popularity, the valuable devices it powers worldwide, and an array of dangerous new Linux malware variants that have emerged in recent years. . It has become apparent that most attacks on Linux systems can be attributed to misconfigurations and poor administration - and failure to properly secure the Linux kernel is often at least partially to blame. Kernel security is a key determinant of overall system security, as the Linux kernel is the foundation of the Linux OS and the core interface between a computer’s hardware and its processes. Luckily, the Linux kernel possesses an assortment of effective built-in security defenses - namely, firewalls that use packet filters built into the kernel, Secure Boot, Linux Kernel Lockdown, and SELinux or AppArmor - that administrators should take full advantage of. In this article, we'll examine the importance of robust kernel security and explore various measures you can take to secure the Linux kernel and protect your systems from malware and other exploits. How Secure Is the Linux Kernel? Kernel security is an ongoing concern for Linux system administrators, and securing the kernel is one of the most complex aspects of securing a Linux system. Even though the Linux kernel undergoes 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 OS, and many 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 - withoutrequiring that the victim take any actions. Some of the most notorious Linux kernel security bugs discovered and fixed in recent years include: CVE-2017-18017: This critical vulnerability, which resides in the netfilter tcpmss_mangle_packet function, is highly dangerous due to its central role in filtering network communications by defining the maximum segment size that is allowed for accepting TCP headers. Without these controls, users are susceptible to overflow issues and DoS attacks. The flaw impacts kernel versions before 4.11. CVE-2016-10229: This udp.c bug, which also affects kernel versions before 4.5, allows a remote attacker to execute arbitrary code via UDP traffic, triggering an unsafe second checksum while executing a recv system call with the MSG_PEEK flag. CVE-2016-10150: This use-after-free vulnerability, which impacts kernel versions before 4.8.13, could be exploited by hackers to gain privileges and launch DoS attacks. CVE-2015-8812: This severe vulnerability, which was discovered in the Linux kernel drivers, impacts kernel versions prior to 4.5 and enables 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 impacts kernel versions through 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 to execute arbitrary code via a DCCP packet that triggers a call to either the dccp_new, dccp_packet, or dccp_error function. Tracking advisories is critical in protecting against kernel vulnerabilities and maintaining a secure, updated system. Subscribing to our weekly Linux Advisory Watch newsletter is an easy, convenient way to stay up-to-date on your Linux distribution's latest advisories and updates issues. What is Kernel Self-Protection, and Why Is It Important? Linux kernel-self protection , or the design and implementation of systems andstructures within the Linux kernel to protect against security flaws in the kernel itself, is an excellent way of adding another layer of security to the Linux kernel. It includes defense methods such as attack surface reduction, memory integrity, probabilistic defenses and the prevention of information exposure. 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. Practical Advice for Securing the Linux Kernel Securing the Linux kernel requires a proactive, multi-layered defense strategy. Practical measures you can take to secure the kernel against vulnerabilities and exploits leading to compromise include: Apply Kernel Security Patches The Linux kernel is patched frequently to mitigate the latest security vulnerabilities discovered and, albeit monotonous, staying on top of kernel security updates is imperative to maintaining a secure Linux system. The most straightforward method of updating the Linux kernel is tracking distribution security advisories and applying the latest updates available directly from your Linux distribution. There are three other methods for updating the kernel: on the command line, with kexec, or with a rebootless live kernel patching tool . Updating the kernel from the command line is the method that is most likely to be covered in your distribution’s documentation. However, a major disadvantage of patching the kernel on the command line is that you will need to suffer the downtime of a system reboot. Administrators can quicken rebooting 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 rebootless live kernel patching tool such as Livepatch , Ksplice , Kpatch , Kgraft is generally administrators’ method of choice, but is not a replacement for full kernel upgrades, as it only applies patches for security vulnerabilities orcritical bug fixes. Enable Secure Boot in “Full” or “Thorough” Mode UEFI Secure Boot is a verification mechanism for ensuring that code launched by a device's UEFI firmware is trusted. The feature is designed to prevent malicious code from being loaded and executed before the OS has been loaded. By enabling UEFI Secure Boot in “f ull” or “thorough” mode, administrators can decrease the attack surface on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Thus, no unsigned drivers can be loaded for hardware on systems with UEFI Secure Boot enabled in “full” or “thorough” mode. This makes it far 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 instance, it requires manual intervention any time a kernel or module is upgraded. Using Secure Boot also activates "lockdown" mode, which disables various features that can be used to modify the kernel. We will cover this in more depth in the following section. Use Linux Kernel Lockdown Linux Kernel Lockdown is a kernel configuration option developed to provide a policy to prevent the root account from modifying the kernel code by strengthening the divide between userland processes and kernel code. Thus, in the event that a root account is compromised, having Lockdown mode enabled will make it far more difficult for the compromised account to compromise the rest of the OS. Although Lockdown was not introduced until the release of kernel version 5.4, work on this feature began over a decade ago, and was spearheaded by Google engineer Matthew Garrett. Lockdown support can be activated to experience Linux Kernel Lockdown benefits with the lockdown= kernel parameter. The module has two modes: “integrity” mode and “confidentiality” mode. It is generally advised to use the “integrity”mode, and to only use the “confidentiality” mode for special systems that contain sensitive information that even root shouldn't be permitted to see, such as the EVM signing key which can be used to prevent offline file modification. Using confidentiality mode blocks access to all kernel memory, preventing administrators from being able to inspect and probe 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 of permanently enforcing either the integrity or the confidentiality lockdown mode via SECURITY_LOCKDOWN_LSM_EARLY . All of these configurations are controlled through the Kconfig SECURITY_LOCKDOWN_LSM option for enabling the module and experiencing Linux Kernel Lockdown benefits. Administrators should be aware that using Lockdown prevents various features and modules that can be used to modify the kernel from loading. For instance, Lockdown disables: Loading kernel modules that are not signed by a trusted key, such as out-of-tree modules including DKMS-managed drivers. Using kexec to start an unsigned kernel image. Hibernation and resume from hibernation. User-space access to physical memory and I/O ports. Module parameters used to set memory and I/O port addresses. Writing to MSRs through /dev/cpu/*/msr. The use of custom ACPI methods and tables. ACPI APEI error injection. Enable Kernel Module Signing & Module Loading Rules The Linux kernel supports digital signatures on loadable kernel modules , ensuring that only known and valid modules can be loaded and decreasing a system’s attack surface with this requirement. Kernel module signing must be enabled in the kernel with settings in CONFIG_MODULE_SIG. Administrators can configure the kernelto 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 kernel.modules_disabled=1 command. Sysctl is a way for administrators to communicate directly with the kernel to control how it functions. These functions can also be configured in the /etc/sysctl.conf file. We explain how administrators can harden this file in the following section. Disabling modules completely can drastically reduce a system’s attack surface, but is only practical in special use cases. Harden the Sysctl.conf File The sysctl.conf file is the main kernel parameter configuration point for a Linux system. By using secure defaults, your whole system will benefit from a more secure foundation. With /etc/sysctl.conf you can configure various Linux network and system settings to improve security by: Limiting network-transmitted configuration for IPv4 Limiting network-transmitted configuration for IPv6 Turning on execshield protection Protecting against syn flood attacks Turning on source IP address verification Securing a server’s IP address against spoofing attacks Logging suspicious packets such as spoofed packets, source-routed packets and redirects Enable SELinux or AppArmor Modern Linux systems include the Mandatory Access Control (MAC) security enhancement systems AppArmor or SELinux (depending on the distribution) installed by default to protect against threats such as server misconfigurations, software vulnerabilities and zero-day exploits - which could potentially compromise an entire system without these controls in place. SELinux is installed and enabled by default on CentOS and RedHat Enterprise Linux OSes, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems. These security enhancement systems allow for granular access control with securitypolicies, providing an additional layer of security throughout a system. SELinux defines access controls for the 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 are cached for subjects and objects. If SELinux is unable to make a decision about access based on the cached permissions, the request is forwarded to the security server, which checks for the security context of the subject and object from the SELinux policy database. Permission is then 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 set SELinux to permissive mode . By operating in permissive mode, 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 then use for troubleshooting, debugging, and policy improvements. Like SELinux, Apparmor isolates applications and processes from each other with per-program profiles built into the kernel, as well as any profiles that an administrator has generated. AppArmor can be set to either 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. It is unfortunately quite common for administrators to disable SELinux or AppArmor when they encounter an issue as opposed to learning how to fix the issue with these services enabled. This is a poor administration and security practice, and can detract significantly from a system’s overall security posture by leaving the system susceptible to the very attacks that SELinux or AppArmor are designed to prevent. Implement Strict Permissions When all kernelmemory is writable, it’s easy for attacks to redirect execution flow - making it imperative that kernel memory is protected with a tight set of permissions. Permissions should be as strict as is practical in a given environment. Administrators should begin by ensuring that executive code and read-only data is not writable. The CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX configurations, which seek to make sure that code is not writable, data is not executable, and read-only data is neither writable nor executable, are the default options for the majority of Linux architectures. If these settings are user selectable, an administrator can select ARCH_OPTIONAL_KERNEL_RWX to enable a Kconfig prompt. CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT determines the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled. It is critical that function pointers and sensitive variables, which the kernel looks up and uses to continue execution, are read-only—not writable. Many such variables can be made read-only by setting them “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 userspace memory. These rules can be enforced either via hardware-based restrictions or via emulation. Blocking userspace memory forces attacks to operate entirely in kernel memory. Use AuditD for Ongoing System Monitoring Carefully monitoring the Linux kernel enables administrators to discover security bugs, breaches or policy violations, allowing them to mitigate potential damage caused by these threats and verify the security of their systems. Using the Linux Auditing System (AuditD) is a popular and effective method of monitoring the events that occur on a system. AuditD is a native feature of the Linux kerne l, installed by default in most distributions and runs automatically, that collects information on system activity, such as file permissions modifications, services being enabled ordisabled, and network events, to facilitate the investigation of potential security incidents. It logs information according to its ules and any custom rules an administrator has added. The kernel is uniquely suited to perform these functions because only the kernel can access a system’s devices and memory. Here’s an example of the type of information the AuditD audit daemon provided. It shows users running specific commands like /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" Here’s an example of “aureport” being used to generate a summary report of events on 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 AVC's: 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 ExecutableSummary 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 AuditD must be properly configured and hardened to ensure optimal security and effectiveness. Administrators should check that AuditD’s configuration is immutable using the control option “-e 2” and confirm that logs are stored in a centralized, secure location—ideally, a server dedicated to accepting remote syslog events. AuditD does have some weaknesses that should be considered - namely, bugginess, excessive overhead, lack of granularity, missing container support, and demanding output. Our Final Thoughts on Improving Linux Kernel Security Linux is becoming an increasingly attractive target among cybercriminals due to its growing popularity and the high-value devices it powers worldwide. Effective security is contingent upon 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 on the system is secure. Thus, Linux system administrators must prioritize kernel security and remain vigilant about implementing the tips and best practices discussed in this article to protect against security vulnerabilities and prevent exploits. Do you have questions about securing the Linux kernel or want to discuss the topic more? Reach out to us @lnxsec . We're here to help! . Attacks on Linux systems arise from misconfigurations; explore effective kernel security measures against threats.. support, open-source, community, strict, privilege, system, embedded, architec. . Brittany Day
Jan 22, 2025
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More