For over a decade, system administrators and security engineers seeking to sandbox Linux processes have relied on Seccomp-BPF. By compiling a strict BPF filter that restricts system calls to a tiny whitelist, you could block dangerous operations like ptrace or reboot. But in 2026, sophisticated attackers rarely trigger raw forbidden system calls. Instead, they exploit file path traversals, manipulate symlinks, or weaponize shared memory—vectors that Seccomp is mathematically blind to because it cannot dereference user-space pointers.

In this low-level kernel security masterclass, we dive deep into the next evolution of Linux runtime security: eBPF LSM (Linux Security Modules). Introduced in Linux kernel 5.7 and matured in recent distributions, eBPF LSM allows engineers to write programmatic, context-aware security logic in C or Rust that inspects full file paths, network sockets, and credentials directly in kernel memory before operations execute. We benchmark performance overhead, expose Seccomp’s fatal TOCTOU vulnerability, and show you how to write your first eBPF LSM policy.

eBPF LSM vs. Seccomp: Direct Answer & Architecture Verdict

The Fatal Flaw of Seccomp: The Pointer Dereference Blindspot

To understand why modern security architectures are migrating toward eBPF LSM, one must understand how Seccomp filters operate inside the kernel.

When a process makes a system call—such as openat(AT_FDCWD, "/etc/shadow", O_RDONLY)—the CPU switches to kernel mode. Seccomp-BPF executes at the earliest entry point of the system call dispatcher. The BPF filter receives a pointer to struct seccomp_data, which contains only scalar integer values: the architecture, the instruction pointer, the syscall number (e.g., 257 for openat), and the six raw 64-bit register arguments.

The critical limitation: the second argument (the path "/etc/shadow") is passed as a 64-bit memory address pointing to a user-space memory buffer. Seccomp cannot read user-space memory. It cannot dereference that pointer. If Seccomp attempted to read user memory, a concurrent thread could modify the string between the moment Seccomp inspected it and the moment the kernel opened the file—a classic Time-of-Check to Time-of-Use (TOCTOU) race condition. Consequently, Seccomp can only enforce: “Can this process call openat()?” but can never enforce: “Can this process open /etc/shadow?”

How eBPF LSM Solves the Problem in Kernel Space

Linux Security Modules (LSM) are hook points placed strategically throughout the Linux kernel—the same hooks that power SELinux and AppArmor. These hooks execute after the kernel has validated system call arguments and safely copied user pointers into internal kernel structures (such as struct path or struct sock).

Historically, writing an LSM required compiling an out-of-tree kernel module or wrestling with complex, rigid policy compilers. With eBPF LSM, the Linux kernel allows unprivileged or privileged administrators to load safe, verified eBPF programs directly into these hook points at runtime:

1. Pointer Dereferencing Safety: The eBPF verifier guarantees memory safety. Programs can safely traverse kernel structures using BPF helpers (such as bpf_d_path()) to obtain the canonical, resolved filesystem path, completely neutralizing symlink and TOCTOU exploits.
2. Programmatic Context: An eBPF LSM program can evaluate dynamic logic: “Allow this binary to write to /var/log only if the parent process is systemd and the current network namespace matches container ID 4”.
3. Zero System Reboots: Policies can be loaded, updated, or removed atomically without restarting daemons, compiling kernel modules, or disrupting active state tables.

Comparison Matrix: Seccomp-BPF vs. AppArmor vs. eBPF LSM

Ring Buffer Telemetry: Streaming High-Frequency Kernel Audit Events

In addition to blocking malicious operations, runtime security requires real-time forensic observability. Legacy auditing tools like auditd rely on netlink sockets that degrade performance under heavy system load, frequently dropping audit records or introducing CPU lock contention.

eBPF LSM integrates natively with high-performance BPF Ring Buffers (BPF_MAP_TYPE_RINGBUF). A ring buffer is a memory-mapped, lockless circular buffer shared directly between the Linux kernel and user-space security daemons. When an eBPF LSM probe blocks an illegal operation, it formats an audit record containing the process ID, parent process ID, UID, and canonical file path, pushing the event into the ring buffer via bpf_ringbuf_submit() in under 35 nanoseconds with zero memory allocation overhead.

LSM Stacking Order: How eBPF Interacts with AppArmor & SELinux

Modern Linux kernels support LSM stacking, allowing multiple security modules to evaluate system operations concurrently. When a process executes a system call, the kernel calls each active LSM in the order specified by the lsm= boot parameter:

If any LSM in the chain returns an error (such as -EPERM or -EACCES), the kernel immediately aborts the operation and returns an error to the calling process. By placing bpf at the end of the LSM chain (e.g., lsm=landlock,lockdown,yama,apparmor,bpf), eBPF LSM acts as a programmatic second layer of defense. Standard AppArmor profiles handle broad file access restrictions, while custom eBPF LSM probes enforce surgical, behavioral conditions that static AppArmor profiles cannot express.

The 4:00 PM Actionable eBPF LSM Enabling & Deployment Playbook

To enable and leverage eBPF LSM on modern Linux distributions (Debian 12, Ubuntu 24.04 LTS, or Fedora):

1. Verify Kernel LSM Configuration: Check if your running kernel has BPF LSM enabled:

   # Check active LSM modules
   cat /sys/kernel/security/lsm

   If the output does not contain bpf, edit your bootloader configuration (/etc/default/grub) and append bpf to the active LSM list:

   GRUB_CMDLINE_LINUX="lsm=landlock,lockdown,yama,apparmor,bpf"

   Run update-grub and reboot the host.

2. Anatomy of a Minimalist eBPF LSM Probe: Below is a complete, production-grade eBPF C program that intercepts file execution and blocks any process from executing binaries located in world-writable /tmp directories:

   #include <vmlinux.h>
   #include <bpf/bpf_tracing.h>
   #include <bpf/bpf_helpers.h>
   
   char LICENSE[] SEC("license") = "GPL";
   
   SEC("lsm/bprm_check_security")
   int BPF_PROG(block_tmp_execution, struct linux_binprm *bprm)
   {
       char path[256];
       int len;
   
       // Resolve canonical filesystem path in kernel space
       len = bpf_d_path(&bprm->file->f_path, path, sizeof(path));
       if (len < 0)
           return 0;
   
       // Check if binary execution originates inside /tmp/
       if (path[0] == '/' && path[1] == 't' && path[2] == 'm' && path[3] == 'p' && path[4] == '/') {
           bpf_printk("SecOps Defense: Blocked execution in /tmp: %s\n", path);
           return -1; // EPERM (Operation not permitted)
       }
   
       return 0; // Allow execution
   }

3. Compile and Attach with bpftool: Compile the probe using Clang and load it directly into the kernel:

   # Compile eBPF bytecode targeting BPF architecture
   clang -O2 -g -target bpf -c block_tmp.bpf.c -o block_tmp.bpf.o
   
   # Load and attach directly to the kernel LSM hook
   bpftool prog load block_tmp.bpf.o /sys/fs/bpf/block_tmp type lsm

   Test the policy by attempting to execute a binary from /tmp/test. The kernel instantly returns -EPERM, preventing malware drops and reverse shells with zero system overhead.