Kernel Lockdown Mode: Blocking Root from Modifying the Running Kernel

Problem

Root traditionally has unrestricted access to the running kernel: load and unload modules, write to /dev/mem and /dev/kmem, change MSRs (wrmsr), boot a different kernel via kexec_load, dump the kernel’s memory through /proc/kcore, set custom ACPI tables, and mutate kernel data structures via the bpf() syscall in subtle ways. Each of these is a path from compromised root to a permanent foothold that survives reboot, defeats integrity measurement, or evades runtime detection.

Lockdown is a Linux Security Module (lockdown LSM, mainline since 5.4) that severs this implicit privilege. With lockdown active, even uid=0 cannot perform a defined set of operations that would let it modify or expose the running kernel. The control was originally motivated by Secure Boot — a Secure-Boot-verified kernel must not let userspace replace it at runtime — but lockdown is useful well beyond Secure Boot deployments.

Two modes:

• lockdown=integrity — blocks operations that modify the running kernel image.
• lockdown=confidentiality — blocks integrity operations plus operations that read kernel memory.

Despite being available for years, lockdown is off by default on most non-Secure-Boot installations. The specific gaps in a default configuration:

• insmod/modprobe of unsigned kernel modules succeeds for root.
• kexec_file_load(2) and kexec_load(2) permit booting a different kernel image without a reboot — a perfect persistence mechanism that survives runtime forensics.
• /dev/mem, /dev/kmem, and /dev/port allow direct hardware-state manipulation.
• /proc/kcore, /proc/vmcore, and /sys/kernel/debug/* expose kernel memory.
• wrmsr to performance-monitoring MSRs lets code disable mitigations like SMEP, SMAP, NX.
• iopl(2), ioperm(2), raw PCI access via /sys/bus/pci/.../config.

This article covers enabling lockdown via boot parameter and at runtime, the difference between the two modes, integration with Secure Boot and signed modules, audit logging, and the practical applications that lockdown breaks (so you can plan for them).

Target systems: Linux kernel 5.4+ with CONFIG_SECURITY_LOCKDOWN_LSM=y. Most distros (Ubuntu 20.04+, RHEL 8+, Fedora 32+, Debian 11+) ship lockdown built in. Activation differs.

Threat Model

• Adversary 1 — Compromised root: an attacker has gained root through a privilege-escalation exploit, a credential leak, or a misconfiguration. They want to install a persistent, kernel-resident foothold that survives reboot or hides from runtime monitoring.
• Adversary 2 — Malicious kernel module: an attacker convinces an admin (or automation) to load a kernel module — third-party driver, “monitoring agent” — that contains a rootkit or escalation payload.
• Adversary 3 — Kernel memory exfiltration: an attacker with root reads kernel memory (via /proc/kcore, kexec snapshots, or /dev/mem) to extract secrets — TLS session keys, full-disk-encryption keys, KASLR offsets enabling further exploitation.
• Adversary 4 — kexec persistence: attacker uses kexec_load to boot a modified kernel that pretends to be the original, evading boot-integrity attestation.
• Access level: All adversaries have root inside the OS. Some have CAP_SYS_MODULE / CAP_SYS_ADMIN, all have at least standard root.
• Objective: Persistent foothold across reboots; evasion of EDR/IDS that runs in userspace; extraction of secrets resident in kernel memory.
• Blast radius: Without lockdown, root translates directly to “permanent kernel control.” With lockdown, root is bounded to userspace; a kernel exploit becomes the only path to kernel-level persistence, and even that path is harder if the kernel image must remain Secure-Boot-validated.

Configuration

Step 1: Choose a Mode and Enable at Boot

Append to the kernel command line via /etc/default/grub:

GRUB_CMDLINE_LINUX="... lockdown=confidentiality"

Rebuild grub config and reboot:

sudo update-grub                         # Debian / Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL / Rocky
sudo reboot

Verify:

cat /sys/kernel/security/lockdown
# none [integrity] confidentiality
# (active mode is in brackets)

For most production servers without specific debugging or kernel-tracing requirements, confidentiality is the recommendation. Reserve integrity for hosts where you genuinely need to read kernel memory at runtime (deep debugging, security-research environments).

Step 2: Tighten Lockdown at Runtime

Lockdown can be raised but not lowered without a reboot. From none you can switch to integrity or confidentiality; from integrity you can switch to confidentiality; never the reverse.

echo confidentiality | sudo tee /sys/kernel/security/lockdown
cat /sys/kernel/security/lockdown
# none integrity [confidentiality]

This is useful when you cannot reboot immediately but want to apply lockdown to an already-running system. Add to your hardening playbook to run early in boot via systemd:

# /etc/systemd/system/lockdown-at-boot.service
[Unit]
Description=Raise kernel lockdown to confidentiality
DefaultDependencies=no
After=local-fs.target
Before=basic.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo confidentiality > /sys/kernel/security/lockdown'
RemainAfterExit=yes

[Install]
WantedBy=basic.target

Combined with the boot-parameter approach: the boot parameter sets lockdown before any userspace runs (smallest exposure window); the systemd unit is a defense in case the parameter was missed during a kernel upgrade.

Step 3: Combine With Signed Module Loading

Lockdown by itself blocks unsigned module loading. To allow specific signed modules, configure module signing.

Generate a signing key (one-time):

sudo openssl req -new -x509 -newkey rsa:4096 -keyout /etc/kernel/signing.key \
  -outform DER -out /etc/kernel/signing.x509 -days 365 -nodes \
  -subj "/CN=Production module signing/"

sudo chmod 600 /etc/kernel/signing.key

Sign a module:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file \
  sha256 /etc/kernel/signing.key /etc/kernel/signing.x509 \
  ./mymodule.ko

Enroll the public certificate in the kernel’s trusted keyring (requires Secure Boot or an existing trust path):

# Append to /etc/kernel-img.conf or distro-specific cert location.
sudo mokutil --import /etc/kernel/signing.x509
sudo reboot
# Confirm enrollment in the MOK manager during boot.

Verify a signed module loads under lockdown:

sudo insmod ./mymodule.ko
# Should succeed if signed and the cert is trusted.
sudo insmod ./unsigned.ko
# insmod: ERROR: could not insert module: Permission denied (lockdown blocks)

Step 4: Audit What Lockdown Blocks

Every lockdown denial generates a kernel audit message. Forward to your audit pipeline:

# /etc/audit/rules.d/lockdown.rules
-a always,exit -F arch=b64 -F a0=0 -S init_module -S finit_module
-a always,exit -F arch=b64 -S kexec_load -S kexec_file_load
-w /dev/mem -p rwa -k mem_access
-w /dev/kmem -p rwa -k kmem_access
-w /proc/kcore -p r -k kcore_read

Reload audit rules and watch for denials:

sudo augenrules --load
sudo journalctl -k | grep -E "lockdown|denied" | head -20
# kernel: Lockdown: insmod: unsigned module loading is restricted; see man kernel_lockdown.7

In production: every lockdown denial line should be either a known operator action (signed module load) or an alert-worthy event.

Step 5: Plan for Tooling That Lockdown Breaks

Lockdown breaks legitimate workflows. Inventory and adapt before flipping the switch.

For Kubernetes nodes specifically: kdump is rarely useful in production (workload restart is faster than crash analysis). eBPF-based security observability (Tetragon) works under lockdown because it uses the kernel’s structured BPF helpers, not direct memory reads.

Expected Behaviour

Verify lockdown is active:

cat /sys/kernel/security/lockdown
# none integrity [confidentiality]

# Negative test: attempt a blocked operation and confirm it fails.
sudo insmod /tmp/test_unsigned.ko 2>&1
# insmod: ERROR: could not insert module: Operation not permitted
sudo dmesg | tail -1
# kernel: Lockdown: insmod: unsigned module loading is restricted...

Trade-offs

Failure Modes

Related Articles

• Hardening the Linux Kernel Attack Surface with sysctl and Boot Parameters
• GRUB Boot Hardening for Production Linux Systems
• Linux Kernel Module Loading: Restricting What Loads on Your System
• io_uring Security and Hardening
• Landlock LSM: Unprivileged Kernel Sandboxing