Linux Kernel Hardening: Sysctl, Modules, and LSMs

Linux kernel hardening is not a contest to set the most sysctls. It is the controlled removal of kernel capability that a workload does not need.

The failure mode is predictable. A team copies a long configuration from the internet, applies it to every server, breaks containers or monitoring, and rolls the whole file back. Nothing stays hardened because nobody tied each setting to a threat, an owner, a test, or a recovery path.

Current exploitation data makes that approach indefensible. The CISA Known Exploited Vulnerabilities catalog snapshot released September 2, 2026 contains 1,694 entries. A direct filter of its vendor, product, and name fields returns 28 Linux kernel entries, with seven added since September 3, 2025. That is not a forecast. It is evidence that attackers have used kernel flaws against real systems.

What does Linux kernel hardening actually change?

Linux kernel hardening narrows four things: vulnerable code age, reachable kernel interfaces, the authority to load or alter kernel code, and the damage a process can cause after compromise. Patching matters first. A sysctl may make exploitation harder, but it does not repair vulnerable code.

This is one layer of a wider host program. The system hardening pillar covers identity, services, software, network paths, recovery, and evidence. The Linux hardening checklist puts those controls in production order. Kernel work sits inside both. Treating it as an isolated tuning exercise is how unsafe exceptions survive.

Why must kernel hardening start with support and patching?

Start with the kernel you actually run, not the version string you wish you ran. Record the distribution, package build, architecture, booted image, update source, support end date, and last reboot. Distribution vendors backport fixes, so raw upstream version comparison can create false conclusions. Use the vendor advisory and installed package state together.

Reboot ownership is part of patching. A new package on disk does not protect a host still running the old image. Compare the booted release with the installed release, schedule the restart, run application health checks, and preserve the previous boot entry until the canary passes.

A useful recent marker is Linux 6.18. The official kernel release table records its November 30, 2025 release and projected support through December 2028. It also lists 5.15 and 5.10 support ending in December 2026. That does not mean every organization should compile 6.18. It means teams on an aging line need a dated migration decision, especially when their distribution support ends sooner.

Which sysctl settings reduce useful attacker access?

Choose settings from a threat model, then test them by role. The following small baseline reduces kernel address disclosure, limits access to the kernel log, constrains process tracing, and protects common link attacks. The kernel address and log values are documented in the Linux kernel sysctl documentation. The Yama and file system values follow their companion kernel administration pages. Distribution defaults may already set some of them.

Read the values back after reload and again after reboot. Test debuggers, support tools, crash collection, and application diagnostics before broad deployment. A stricter ptrace_scope value may be right for an appliance and wrong for a development host. The difference is workload evidence, not personal preference.

Be especially careful with network sysctls copied from generic guides. Reverse path filtering can break asymmetric routing. Disabling IPv6 can break software that expects loopback behavior. Namespace settings can affect containers. If the team cannot name the attack path and the acceptance test, leave the line out.

How should you control kernel modules without breaking boot?

Modules extend the most privileged code on the host. Inventory what is loaded, what the role needs, and what can load automatically. Remove unused hardware and protocol support from custom images where practical. For standard distribution kernels, deny a small set only after proving the role does not need it.

The deny file controls future loads. It does not unload a module already in use, remove it from an early boot image, or prove that another alias cannot request it. Rebuild the early boot image when the distribution requires it, reboot a canary, then check lsmod and the journal.

Signed modules and Secure Boot create a stronger boundary than a long deny list. The kernel's self protection guidance recommends signed modules or disabling module loading for systems that must resist even a privileged local attacker. Writing 1 to kernel.modules_disabled cannot be reversed before reboot. That makes it a late boot control for stable appliances, not a casual fleet default.

What do Linux Security Modules and lockdown add?

SELinux and AppArmor restrict actions after ordinary file permissions approve them. Keep the distribution's chosen major Linux Security Module in enforcing mode, start from a maintained policy, and investigate denials. Turning enforcement off to clear a ticket converts useful evidence into silence.

The first command reads the active LSM list from the running kernel. The next commands check common enforcement and lockdown interfaces. An absent file is not a pass. It may mean the kernel lacks the feature, securityfs is not mounted, or the distribution exposes the state elsewhere.

Lockdown limits paths that can modify or read sensitive kernel state, often when Secure Boot is active. It can collide with unsigned drivers, hardware diagnostics, hibernation, and low level support tools. Test those paths in a hardware cohort. Do not discover a recovery agent depends on an unsigned module during an outage.

Which build and runtime protections matter?

Most teams should consume their distribution kernel rather than maintain a custom build. Still, security needs to know whether the package enables address randomization, strict memory permissions, stack protection, hardened allocator behavior, module signature enforcement, seccomp, and the required LSM. Inspect the distribution config under /boot or through /proc/config.gz when available.

Runtime reduction matters too. Drop Linux capabilities from services and containers, enable seccomp profiles, avoid privileged containers, and remove device access the workload does not need. A hardened kernel below a container with every capability is an expensive foundation under an open door.

Use CIS Benchmarks as a maintained policy source, not a blind repair script. Record every tailored setting, its reason, the roles affected, the test result, and the next review date. Our hardening automation guide shows how to stage those changes with canaries and rollback.

How do you deploy kernel hardening safely?

1. Observe first. Capture booted kernel, loaded modules, active LSMs, effective sysctls, workload health, and current alerts.
2. Group by role. Separate container hosts, databases, build systems, appliances, and developer machines. They do not share one safe baseline.
3. Test one change class. Patch, sysctl, module policy, and lockdown have different failure modes. Keep their releases separate.
4. Canary with recovery. Preserve console access and the previous kernel. Define the health failure that triggers rollback before deployment.
5. Prove after reboot. Read effective state, exercise the workload, inspect denials, and store timestamped evidence.
6. Watch for drift. Recheck after kernel, driver, image, or role changes. Expire exceptions instead of carrying them forever.

The evidence record should be small enough to use. Store the asset and role, observed kernel package, booted release, setting name, effective value, source policy, observation time, test result, exception owner, and next review. Keep collection failure separate from control failure. If an agent stops reporting, the state is unknown. Calling it failed creates noise. Calling it passed creates risk.

Rollback also needs evidence. Record which previous image remains bootable, how long it will remain available, who can use console access, and which alert stops the wave. A rollback that depends on the same network path a setting may break is not a rollback. For remote sites, prove the out of band path before the first canary.

What does a kernel hardening rollout cost?

Suppose 600 servers need 12 kernel checks. That creates 7,200 observations. At two minutes of manual review per result, the team spends 240 hours reading values. If one shared image accounts for 420 servers, fix and verify that image once, then sample runtime state across the cohort. The unit of work should be a shared cause, not a spreadsheet cell.

Context changes the order. An old kernel on an isolated build worker is not the same decision as the same kernel on a public server that exposes a reachable service. The CISA KEV catalog guide explains how confirmed exploitation should alter patch priority without replacing local evidence.

Which kernel hardening mistakes cause the most damage?

Copying a giant sysctl file is the obvious mistake. The quieter ones are worse: treating a package install as a completed reboot, disabling module loading before all drivers are present, leaving an LSM in permissive mode, and reporting intent files as effective state. Another bad habit is combining patch, boot, module, and network changes in one release. When the canary fails, nobody knows which control caused it.

Stronger is not always safer. A value that blocks crash collection can slow incident response. A module rule that breaks storage can erase availability. Kernel hardening earns its place when the threat reduction survives the workload test and the operating team can maintain it.

Frequently asked questions

What is the best first Linux kernel hardening control?

Put the host on a supported vendor kernel, make reboot ownership explicit, and prove the running image is the patched image. Configuration defenses come after vulnerable code is under a reliable repair process.

Should I use every recommended sysctl?

No. Use settings tied to a threat and tested against a defined server role. Network paths, containers, debuggers, and support tools can fail when a generic baseline ignores workload behavior.

Is SELinux or AppArmor enough to harden the kernel?

They constrain actions through the LSM framework, but they are not enough. They do not replace patching, module controls, Secure Boot, reduced capabilities, workload isolation, or runtime verification.

How often should kernel hardening be verified?

Verify after every kernel or image update, after reboot, after a role change, and on a fixed cadence based on exposure. Track evidence age so a silent host cannot retain an old pass.

The executive takeaway

Pick one production role. Confirm the booted kernel, close its patch and reboot gap, apply five justified settings, verify its active LSM and module state, then reboot a canary with a tested recovery path. Deep endpoint context with AI driven analysis can connect that state to a vulnerability decision, but the team still owns the change. A smaller kernel attack surface is valuable only when production can keep it small.