Abstract

Extended Berkeley Packet Filter (eBPF) has become the dominant primitive for cloud-native runtime security. Falco, Tetragon, Cilium’s network policy engine, and a growing list of commercial products use eBPF probes to observe kernel events - syscalls, file opens, network connections - without modifying the kernel or inserting loadable kernel modules. This positioning as a security tool is compelling, but eBPF’s privileged execution context and expanding instruction set also create a meaningful attack surface that security architects need to account for explicitly.

What Runtime Security via eBPF Actually Does

eBPF security tools attach programs to kernel hooks via kprobes, tracepoints, or LSM (Linux Security Module) hooks, depending on the kernel version and the capability required. The programs run in a sandboxed JIT-compiled environment inside the kernel and emit events to userspace via ring buffers. Tetragon, developed by Isovalent, extends this with in-kernel enforcement - the probe itself can kill a process or block a syscall before returning to userspace, reducing the window between observation and response. This is a meaningful advantage over audit-log-based approaches, where detection and enforcement are decoupled by design. Falco, by contrast, operates as a pure detection engine and relies on downstream SOAR or policy engines for enforcement.

The Attack Surface eBPF Introduces

The JIT compiler and verifier in the kernel are sophisticated pieces of code, and they have had serious vulnerabilities. CVE-2021-3490, CVE-2022-23222, and several others in the 2021-2024 window allowed unprivileged or CAP_BPF-privileged eBPF programs to escape the verifier sandbox and achieve kernel code execution. The broader issue is structural: eBPF programs loaded by the security tool itself require elevated privileges. If the security agent is compromised, those privileges are available to the attacker. Additionally, eBPF programs can be used offensively - malicious eBPF rootkits like TripleCross (published as a research proof of concept in 2022) demonstrate that the same observation primitives can hide processes, intercept syscalls, and redirect network traffic from kernel space, making them invisible to userspace security tools including other eBPF agents.

Practical Guidance for Security Architects

The right posture is not to avoid eBPF-based security, but to scope its privileges precisely. Use CAP_BPF and CAP_PERFMON instead of full CAP_SYS_ADMIN where kernel versions permit (5.8+). Pin eBPF maps with strict permissions and audit who can load new programs at runtime - treat it similarly to kernel module loading policy. On Kubernetes clusters, enforce that only designated namespaces and service accounts can load eBPF programs, using admission controllers. Monitor the eBPF subsystem itself: track bpf() syscall usage across the cluster via audit rules, and alert on unexpected program loads outside the known security agent set. The verifier’s attack surface is a compelling argument for keeping kernel versions current, since many verifier bugs are backported slowly or not at all in enterprise-grade kernels.