BPF Performance Tools Chapter 11 — Security Explained: execsnoop, capable, Connection Monitoring

// the one-minute version

The same BPF that finds performance problems gives runtime security observability: a low-overhead, hard-to-evade view of what's actually happening on a host. execsnoop logs every program executed; tcpconnect/tcpaccept log every network connection; opensnoop logs file access; capable shows privilege (capability) checks. Together they build an audit trail — useful for detecting suspicious execs, unexpected connections, and privilege use. BPF also underpins enforcement (seccomp, LSM/KRSI) — but this chapter is mainly about seeing, with a defensive, monitoring lens.

BPF's reach and low overhead make it a natural fit for security observability — watching, from inside the kernel, exactly what programs run, what they connect to, what files they touch, and what privileges they exercise. Because it traces kernel events directly, it's harder to evade than user-space logging and cheap enough to run continuously. This chapter applies the performance toolkit to a defensive question: building a faithful runtime picture of host activity to spot the suspicious. It's monitoring, not exploitation — visibility for defenders.

01 Why BPF for security observability

Traditional security logging often relies on the application or a user-space agent to report what it did — which a compromised process can omit or fake. BPF observes at the kernel level: the syscall actually happened, the connection was actually made, regardless of what user-space claims. That makes it a strong source for a faithful activity record. Combined with its low, bounded overhead, you can run continuous monitoring of execs, connections, file access, and privilege checks without the cost of heavier auditing — a real-time, hard-to-evade view of the host.

key ideaKernel-level visibility is harder to evade than user-space logging. A compromised process can suppress its own logs, but it can't hide the execve, the connect, or the file open from the kernel — and BPF watches the kernel. That fidelity, plus continuous low-overhead operation, is why BPF is a strong foundation for runtime security observability and modern tools (Falco, Tetragon, Tracee) build on it.

02 Process execution: execsnoop

The cornerstone of host monitoring. execsnoop logs every program executed (execve) with the command, arguments, PID, and parent — a complete record of what ran. For security this is gold: you see exactly which binaries and scripts executed, in what order, spawned by what. Suspicious patterns jump out — a web server spawning a shell, an unexpected interpreter, a known-bad command, a process running from /tmp. Because execve is comparatively low-frequency, continuous execsnoop-style monitoring is cheap, and it's the same short-lived-process visibility that helped on the CPU side (Chapter 6).

03 Connection monitoring: tcpconnect, tcpaccept

Network activity is central to detecting compromise — data exfiltration, command-and-control, lateral movement. tcpconnect logs every outbound connection attempt (which process connected to which address/port), and tcpaccept logs inbound accepts. A defender watches for connections that shouldn't exist: a database reaching out to the internet, a process connecting to an unfamiliar host, an unexpected listener. Paired with tcplife (Chapter 10) for bytes and duration, you can spot a process quietly shipping data out. The kernel-level vantage means the connection is recorded even if the malicious process tries to stay quiet.

04 File access: opensnoop

What files a process touches is revealing. opensnoop logs every file open with the process and path (and whether it succeeded). For security, this surfaces access to sensitive files — /etc/shadow, SSH keys, credential stores — and unexpected reads or writes. It also catches reconnaissance: a process enumerating config files, probing paths (lots of failed opens), or reading where it has no business. Combined with the exec record, you get "this unexpected process ran, then read these sensitive files, then connected out" — a narrative an attacker can't easily erase from the kernel's view.

Fig 1 — Combining BPF tools builds a faithful, hard-to-evade narrative of host activity for defenders.

05 Privilege checks: capable

Linux privileges are split into capabilities (e.g. CAP_NET_ADMIN, CAP_SYS_ADMIN), checked by the kernel when a process attempts a privileged action. capable traces those capability checks — showing which process requested which privilege. For security this reveals privilege use and potential escalation: a process exercising capabilities it shouldn't need, or a sudden CAP_SYS_ADMIN check from an unexpected program. It's also useful defensively for tightening — seeing exactly which capabilities a service actually uses so you can drop the rest (least privilege). The kernel-level view shows the real privilege behavior, not the declared intent.

06 Other signals and privilege changes

More security-relevant tracing. Tools and one-liners can watch setuid/setgid changes (a process changing its user — a classic escalation step), module loads (modsnoop — kernel modules are a rootkit vector), TTY activity, and permission-denied events (eperm-style — failed access attempts that may indicate probing). Each is a kernel event BPF can trace continuously. The pattern is the same throughout: pick the kernel events that matter for your threat model and trace them with low overhead, building a behavioral baseline so anomalies stand out.

the catchBPF observability is powerful but it is not a complete security solution by itself, and treating it as one is the trap. It needs root/privileged access to run (so it assumes you already control the host), the probes can have gaps (a kprobe on the wrong function, an event type you didn't trace), very high event rates can drop events under load (losing exactly the activity you wanted), and naive per-event logging can be heavy. It's an excellent signal source that feeds detection — best used through mature tools (Falco, Tetragon, Tracee) that handle event loss, rule logic, and enforcement — not a turnkey defense you point at a host and forget.

07 Enforcement: seccomp and LSM/KRSI

Beyond observing, BPF also enforces. seccomp-BPF filters which syscalls a process may make — a sandbox that kills or blocks disallowed calls (used by container runtimes and browsers). KRSI / BPF LSM lets BPF programs attach to Linux Security Module hooks to make allow/deny decisions on security-relevant operations. These turn BPF from a watcher into a guard. This book focuses on observability, but knowing enforcement exists matters: the same instrumentation points that report an action can, with LSM/seccomp, prevent it — the basis of modern eBPF security platforms.

08 A security-observability workflow

(1) Establish a baseline of normal — what execs, connections, file access, and capabilities are expected for this host/service. (2) Continuously monitor execs (execsnoop), connections (tcpconnect/tcpaccept), sensitive file access (opensnoop), and privilege checks (capable). (3) Alert on deviations — an unexpected binary, a connection to a new host, a read of a credential file, an unusual capability. (4) On an incident, use the kernel-level trail to reconstruct what happened. (5) For production, build on mature BPF security tools that handle event-loss and rules rather than raw scripts. Baseline, watch the key events, alert on anomalies.

common catches & gotchas

Treating BPF as a full defense — It's a signal source, not a turnkey solution. Use mature tools (Falco/Tetragon/Tracee) for rules, event-loss handling, and enforcement.
Event loss under load — Very high event rates can drop events — exactly the ones you may care about. Use per-event buffers sized appropriately and aggregation where possible.
Probe gaps — A kprobe on the wrong function or an untraced event type leaves blind spots. Prefer stable, well-chosen tracepoints and validate coverage.
Assumes you control the host — BPF needs root/privilege; it monitors a host you already own, not an attacker's.
kprobe fragility — Security tools on kprobes can break or silently miss after kernel upgrades. Prefer tracepoints/LSM hooks; re-verify.
Per-event overhead — Naive logging of high-frequency events is heavy. Aggregate or filter; reserve full per-event logging for low-rate, high-value events like execs.

09 Questions engineers actually ask

Why use BPF for security instead of app logs?

BPF observes at the kernel level, so it records the actual execve, connect, or file open regardless of what a (possibly compromised) user-space process claims. That fidelity, plus low continuous overhead, makes it a strong, hard-to-evade signal source — though it's a foundation for detection tools, not a complete solution.

How do I see every program that runs on a host?

execsnoop logs every execve with command, args, PID, and parent. Run continuously, it's a complete execution record — ideal for spotting unexpected binaries, a server spawning a shell, or commands running from suspicious paths. Execs are low-frequency, so the overhead is small.

Can BPF detect data exfiltration?

It can surface the signals: tcpconnect shows unexpected outbound connections, and tcplife shows bytes and duration per connection. A process connecting to an unfamiliar host and shipping data out stands out. BPF provides the visibility; detection logic (baselines, rules) turns it into an alert.

What does capable show me?

It traces Linux capability checks — which process requested which privilege (e.g. CAP_SYS_ADMIN). Useful for spotting privilege escalation (an unexpected program exercising high privilege) and for least-privilege tightening (seeing which capabilities a service actually uses so you can drop the rest).

Can BPF block attacks, or only watch?

Both. This chapter focuses on observability, but seccomp-BPF filters syscalls (sandboxing) and BPF LSM/KRSI attaches to security hooks to allow/deny operations. The same instrumentation that reports an action can, with those, prevent it — the basis of modern eBPF security platforms.

10 Key takeaways

BPF gives kernel-level security observability — faithful, low-overhead, hard to evade.
execsnoop records every program run; tcpconnect/tcpaccept record every connection.
opensnoop reveals file access (secrets, recon); capable reveals privilege use.
Combined, the tools build a narrative of host activity an attacker can't easily erase from the kernel.
BPF is a signal source, not a turnkey defense — mind event loss, probe gaps, and overhead; build on mature tools.
BPF also enforces via seccomp and LSM/KRSI — the basis of eBPF security platforms.
Workflow: baseline normal, monitor key events, alert on deviations.

// chapter cheatsheetsecurity observability

execution & privilege

execsnoopEvery program executed — command, args, parent.

capableCapability (privilege) checks per process.

setuidssetuid/setgid privilege changes.

network

tcpconnect · tcpacceptOutbound / inbound connections — exfil & C2 signals.

tcplifeBytes + duration per connection.

file & module access

opensnoopFile opens — sensitive-file access, recon (failed opens).

modsnoopKernel module loads (rootkit vector).

enforcement (beyond watching)

seccomp-BPFFilter allowed syscalls (sandbox).

BPF LSM / KRSIAllow/deny at security hooks.

production

Falco · Tetragon · TraceeMature eBPF platforms — rules + event-loss handling.

11 Wrapping up

The performance toolkit doubles as a defender's lens: execsnoop, connection tracing, file-access and capability monitoring build a faithful, kernel-level record of host activity — a signal source for detection, with seccomp/LSM for enforcement, best wielded through mature platforms. Next the book turns to a thornier observability problem: tracing across the gap between compiled, JIT, and interpreted code. Next: Languages.

BPF Performance Tools Chapter 11 — Security.