CoursesLinux hardeningKernel & filesystem

Kernel & memory hardening (sysctl)

ptrace, dmesg, kptr, and friends.

Advanced12 min · lesson 9 of 16

Beyond networking, sysctl exposes kernel and memory protections that make a host harder to exploit and harder to investigate from — for an attacker. These settings do not stop an initial compromise so much as limit what an attacker can do once inside and how much the kernel helps them. A few high-value ones: restrict ptrace so one process cannot attach to and read another’s memory, hide kernel pointers so exploits cannot easily find their targets, and restrict access to the kernel log.

/etc/sysctl.d/90-kernel-hardening.conf
kernel.yama.ptrace_scope = 1 # a process may only ptrace its own children
kernel.kptr_restrict = 2 # hide kernel pointers from /proc (defeats many exploits)
kernel.dmesg_restrict = 1 # only root reads the kernel ring buffer
kernel.perf_event_paranoid = 3 # restrict perf (a powerful info-leak surface)
kernel.unprivileged_bpf_disabled = 1 # no unprivileged BPF (a known escalation surface)

Why these matter to an attacker

Each setting closes a technique. ptrace_scope stops a compromised process from reading secrets out of another process’s memory (a common way to steal credentials from a running service). kptr_restrict and dmesg_restrict deny an exploit the address information and kernel messages it uses to build a reliable escalation. Disabling unprivileged BPF removes an entire class of local privilege-escalation vulnerabilities. Individually modest, together they turn "landed a foothold, now escalate to root" from routine into difficult.

Address-space and link protections

Some protections are on by default but worth confirming, and a couple more are worth adding. ASLR (randomizing memory layout so exploits cannot predict addresses) should be at its maximum. And restricting hardlinks and symlinks (protected_hardlinks, protected_symlinks) closes a family of race-condition attacks where an attacker swaps a link under a privileged program. These are exactly the checks a CIS benchmark enumerates — not because any one is dramatic, but because their collective absence is what makes a host soft.

/etc/sysctl.d/90-kernel-hardening.conf
kernel.randomize_va_space = 2 # full ASLR
fs.protected_hardlinks = 1 # close hardlink race attacks
fs.protected_symlinks = 1 # close symlink race attacks
fs.suid_dumpable = 0 # never core-dump SUID programs (they hold secrets)
Test kernel tunables against your workload
Kernel hardening sysctls are generally safe, but a few can affect specific software — ptrace_scope can break a debugger or an APM agent that legitimately traces processes, and disabling unprivileged BPF can affect some observability tools. Apply them, then verify your actual services and monitoring still work, and document any exception you must make. Hardening that silently breaks your debugging tools gets reverted wholesale; hardening applied and verified sticks.