Linux Security Modules and Current Threat Landscape (2025)

Linux Security Modules: a practical intro (with real-world wins)

Linux Security Modules (LSMs) are kernel hooks that let you enforce policies beyond Unix permissions. Pick one “major MAC” (SELinux or AppArmor), add a few focused helpers (Yama, SafeSetID, LoadPin, Lockdown), and combine with seccomp, capabilities, and integrity checks (IMA/EVM). This layered baseline dramatically shrinks blast radius for the three big threats: priv-esc, file tampering, and rootkits.

What LSMs are:

LSMs are checkpoints inside the kernel (file open, exec, networking, etc.). A security module can allow/deny/log those operations based on policy, so even if a process has Linux DAC permissions, policy can still say no.
Common modules:

• SELinux (label-based MAC, very granular; “targeted” and MLS policies)

• AppArmor (path-based MAC; friendly per-app profiles)

• Smack / TOMOYO (lighter MAC options, popular in embedded)

• Yama (ptrace/hardlink restrictions), SafeSetID (limits setuid transitions)

• LoadPin (only load kernel modules from a trusted FS)

• Lockdown (protects kernel from even root, esp. with Secure Boot)

• IMA/EVM / IPE (measure/appraise/sign files; enforce code integrity)

• Landlock (apps sandbox themselves without root; emerging)

• BPF-LSM/KRSI (programmable security logic using eBPF; emerging)

You can stack multiple LSMs: one major MAC + helpers.

Where LSMs matter most

1) Containers & Kubernetes

• Why: Escapes and lateral movement are the name of the game.

• Do this:

  • Enable SELinux (e.g., OpenShift style) or AppArmor profiles for pods.

  • Keep seccomp default profile on; drop capabilities aggressively.

  • Use Yama (no cross-container ptrace), LoadPin + module signing on hosts.

  • Consider IMA/EVM or read-only root filesystems for tamper resistance.

2) General-purpose desktops

• Why: Browsers, editors, and tools handle untrusted content.

• Do this:

  • Keep SELinux/AppArmor on; sandbox apps (Snaps/Flatpak + profiles).

  • Lock down kernel paths (Lockdown, Secure Boot) to deter rootkits.

  • Use least-privilege (cap drops) even for dev tools and local services.

3) Critical infrastructure / appliances / IoT

• Why: Integrity and uptime trump convenience.

• Do this:

  • Strict SELinux/Smack policies; minimal userspace.

  • IMA/EVM (or IPE) to only run signed/verified code.

  • LoadPin + Lockdown + module signatures; read-only, verity-backed roots.

The threats (and how LSMs blunt them)

1) Privilege escalation (user → root, container → host)

• Tactics: kernel bugs, sloppy setuid, abusing capabilities.

• LSM countermoves:

  • SELinux/AppArmor confine compromised services—post-exploit damage is contained.

  • Yama blocks ptrace games; SafeSetID fences UID jumps.

  • Lockdown/module-signature + fast patching keep kernel off-limits.

2) File tampering & persistence (backdoors, ransomware, supply-chain)

• Tactics: edit /etc/*, trojan binaries, poison image layers.

• LSM countermoves:

  • MAC rules deny writes outside allowed paths (e.g., web server can’t touch /etc).

  • IMA/EVM/IPE stop execution of altered/unsigned binaries.

  • Immutable/verity roots + LoadPin prevent “write-then-persist” tricks.

3) Rootkits & boot-level malware

• Tactics: malicious LKMs, syscall hooking, bootkits that disable defenses.

• LSM countermoves:

  • Lockdown + signed modules + Secure Boot block unsigned kernel code.

  • IMA can flag tampering; BPF-LSM/KRSI provides deeper runtime visibility.

  • Defense-in-depth means a rootkit must defeat multiple independent checks.

You can download the full article for free: