sodcalculator

10 Tech How-To

Linux Kernel Security Hardening: How to Check

Guide 10-36134 · Updated · Step by step

This guide shows you how to verify whether your Linux kernel has security hardening features enabled, such as ASLR, stack protector, and hardened usercopy. You’ll learn to inspect kernel configuration files and runtime settings using standard commands. No prior kernel expertise is needed, but basic familiarity with the terminal is helpful.

What You’ll Need

  • A Linux system with root or sudo access (some commands require it).
  • Access to a terminal emulator.
  • The grep, uname, and cat commands (usually pre-installed).
  • For runtime checks, the sysctl command (part of procps-ng).

Step-by-Step

  1. Identify your kernel version. Run uname -r to see the exact kernel release. This tells you which config file to look for (e.g., 5.15.0-91-generic).
  2. Locate the kernel configuration file. The most common paths are /boot/config-$(uname -r) and /proc/config.gz (if CONFIG_IKCONFIG is enabled). If neither exists, the config may be in /lib/modules/$(uname -r)/build/.config (requires kernel headers).
  3. Extract the config if it’s compressed. If you have /proc/config.gz, run zcat /proc/config.gz > /tmp/kernel_config to decompress it to a readable file.
  4. Check for core hardening options. Use grep -E 'CONFIG_(DEBUG_INFO|GCC_PLUGIN_STRUCTLEAK|STACKPROTECTOR|HARDENED_USERCOPY|FORTIFY_SOURCE|RANDOMIZE_BASE|PAGE_TABLE_ISOLATION|SLAB_FREELIST_HARDENED|SLAB_FREELIST_RANDOM|REFCOUNT_FULL)' /path/to/config. Look for =y (enabled) or =m (module) versus # CONFIG_... is not set (disabled).
  5. Verify runtime ASLR setting. Run sysctl kernel.randomize_va_space. A value of 2 means full ASLR (recommended), 1 means partial (stack, library, mmap), and 0 means disabled.
  6. Check for kernel pointer hiding. Run sysctl kernel.kptr_restrict. A value of 1 or 2 restricts /proc/kallsyms output, hiding kernel addresses from unprivileged users.
  7. Inspect dmesg for hardening messages. Run dmesg | grep -i 'KASLR|SMEP|SMAP|NX'. Look for lines like Kernel/User page tables isolation: enabled or KASLR enabled.
  8. Check for SMEP/SMAP support. Run grep -E 'smep|smap' /proc/cpuinfo. If the flags are present, the CPU supports these features, but the kernel must also have them enabled (CONFIG_X86_SMAP, CONFIG_X86_SMEP).
  9. Verify hardened usercopy at runtime (if applicable). Run cat /sys/kernel/debug/usercopy/whitelist (if mounted) or check dmesg for usercopy violations. This is more advanced; the config option is a good proxy.
  10. Check for lockdown mode (if enabled). Run cat /sys/kernel/security/lockdown. If it shows none, lockdown is not active; integrity or confidentiality indicates a higher security state.

Common Mistakes

  • Assuming a distro kernel has all hardening options. Many distros enable most, but some (like DEBUG_INFO) are often disabled for performance. Always check each option individually.
  • Confusing CPU support with kernel enablement. Having SMEP/SMAP in /proc/cpuinfo does not guarantee the kernel uses them; you must also see the CONFIG options set to y.
  • Reading the wrong config file. If you have multiple kernels installed, ensure you’re checking the config for the currently running kernel, not the latest one.
  • Ignoring the difference between =y and =m. Some hardening features can be built as modules, but for security-critical ones, =y is required to be active at boot.
  • Not checking runtime values. A config option can be enabled, but a boot parameter (like nokaslr) can override it. Always verify with sysctl or dmesg.

Tips

  • Use grep -i to make your searches case-insensitive; config options are uppercase, but comments might differ.
  • If you’re on a distribution like Ubuntu, you can install linux-tools-common and use extract-ikconfig to pull the config from the kernel image itself.
  • For a quick summary, try grep -E 'CONFIG_(STACKPROTECTOR|HARDENED_USERCOPY|FORTIFY_SOURCE|RANDOMIZE_BASE)' /boot/config-$(uname -r) | grep '=y' to list only enabled options.
  • Consider using a tool like lynis (if installed) to get a security audit that includes kernel hardening checks, but verify its findings manually.
  • Keep your kernel updated; newer kernels often include additional hardening improvements and backported fixes.

Troubleshooting

No config file found. If /boot/config-$(uname -r) and /proc/config.gz don’t exist, your kernel may have been built without CONFIG_IKCONFIG. In that case, you can try to extract it from the kernel binary using extract-ikconfig /boot/vmlinuz-$(uname -r) (if the tool is installed). If that fails, you may need to rely on runtime checks alone.

sysctl permission denied. Some sysctl variables are read-only or require root. Use sudo sysctl kernel.randomize_va_space to see the value. If you get a ‘permission denied’ even with sudo, the variable may be namespaced; try cat /proc/sys/kernel/randomize_va_space instead.

dmesg shows nothing relevant. Some kernels don’t log hardening messages at boot. Try dmesg | grep -i 'Kernel/User page tables isolation' or check journalctl -k if you use systemd. If still nothing, rely on config and sysctl checks.

Config shows options as not set, but you expected them. This can happen if the option is not applicable to your architecture (e.g., PAX on ARM) or if the distro disabled it. Check the kernel documentation for the specific option to understand the conditions.

You see ‘Cannot compute’ or errors in sysctl. This is unlikely with sysctl, but if you’re using a script, ensure you’re not mixing up variable names. Use sysctl -a | grep kernel to list all kernel variables.

Frequently Asked Questions

Q: What is the most important hardening feature to check?
A: ASLR (kernel.randomize_va_space=2) and stack protector (CONFIG_STACKPROTECTOR=y) are critical. Without them, exploitation becomes significantly easier.

Q: Can I enable hardening features on a running kernel?
A: Some runtime settings (like ASLR) can be changed with sysctl, but most compile-time options require a kernel rebuild. You can’t enable CONFIG_HARDENED_USERCOPY without recompiling.

Q: Does a hardened kernel affect performance?
A: Slightly. Features like SMAP/SMEP and hardened usercopy add minimal overhead, but the security benefit usually outweighs the tiny performance cost.

Q: My distro kernel shows many options as not set. Is it insecure?
A: Not necessarily. Some options are for debugging or specific use cases. Focus on the core ones listed in Step 4. If those are missing, consider a security-focused kernel like linux-hardened from Arch or a custom build.

Q: How do I check if KASLR is actually active?
A: Run dmesg | grep -i kaslr. If you see Kernel Offset: 0x..., it’s enabled. Alternatively, check cat /proc/kallsyms | head -1; if addresses are randomized (not starting with 0x0), it’s active.

Q: What is the difference between SMEP and SMAP?
A: SMEP (Supervisor Mode Execution Prevention) prevents the kernel from executing code in user-space pages. SMAP (Supervisor Mode Access Prevention) prevents the kernel from reading or writing user-space pages unless explicitly allowed. Both are important.

Related

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →