Security¶

Security considerations for using this tutorial resource: the privilege model its exercises require, isolation practices for running them, supply-chain notes for consuming its distributed artifacts, and dual-use warnings for specific lessons. Content sourced from lesson materials read August 2026 plus documented kernel eBPF privilege semantics.

Privilege Model¶

Every executable lesson requires root. On modern kernels (5.8+), the equivalent fine-grained capabilities replace blanket root for production-style loading:

Capability	Grants	Relevant to
`CAP_BPF`	program/map load, most `bpf()` operations	every lesson
`CAP_PERFMON`	performance monitoring, uprobes/kprobes attach	tracing lessons 1-14, 30-40
`CAP_NET_ADMIN`	XDP/tc/netfilter-class attachments	networking lessons 20-21, 41-42, 50, 53
`CAP_SYS_ADMIN`	legacy catch-all on older kernels, BTF write paths, LSM hook attachment path enablement	lesson 19 (BPF LSM)

Verify whether your distro disables unprivileged eBPF entirely (recommended hardening state, since early lessons assume privileged loading anyway):

sysctl kernel.unprivileged_bpf_disabled

Lesson 0's framing

The tutorial presents the verifier as the safety boundary: programs undergo static proof before execution, preventing kernel crashes, memory unsafety, and information leaks regardless of caller privileges. JIT compilation then translates bytecode to native code with W^X discipline. These guarantees protect the kernel — not the data an authorized tracer collects.

Data Sensitivity While Learning¶

Several lessons decode genuinely sensitive material by design:

lesson 30 (sslsniff) attaches uprobes to OpenSSL/BoringSSL/GnuTLS entry points and emits TLS plaintext — running it captures any HTTPS traffic of local applications.
lessons 5, 15, 37 capture user-space function arguments (shell input, JVM GC telemetry, Rust binaries).
lesson 39-40 record nginx request URLs and MySQL queries verbatim.

Treat these like credential-dumping tools: run only on machines you own or are explicitly authorized to instrument. Shared hosts, employer laptops, and CI runners shared across teams are poor practice targets even when technically permitted by root access.

Isolation Practice¶

Disposable VM preferred — the compatibility matrix shows Ubuntu x86_64/arm64 runners as the validated baseline; a snapshot-resettable VM (e.g., stock Ubuntu cloud image) contains mistakes cleanly. Enable nested virtualization note applies if testing XDP over virtual links.
Android lesson (22) requires a device or emulator — the emulator route keeps kernel experiments off any personal handset.
Networking lessons bind to real interfaces (biopattern wants block devices, XDP lessons name a NIC). Prefer lab bridges or veth pairs so host connectivity isn't collateral damage.
bleeding-edge kernels — lessons gated at 6.19/7.0 features imply custom-mainline test VMs, never production or daily-driver systems.

Dual-Use Lesson Warnings¶

A deliberate course arc teaches offense-shaped primitives so defenders understand attacker technique:

Lesson	Technique demonstrated	Handling caution
24-hide	hiding PIDs/files from user space	run in isolated namespace/kernel only
25-signal	terminating arbitrary PIDs from inside BPF (`bpf_send_signal`)	scope PID filters before loading
26-sudo	privilege escalation via file-content manipulation	textbook demonstration environment only
27-replace	transparent tampering of file reads	same
34-syscall	rewriting live syscall arguments	can corrupt unrelated processes without filters
51-tcp-quarantine	severing established connections precisely	disruptive by intent; lab networks

None of these lessons publish exploit chains beyond well-known kernel-programmability concepts; value is defender familiarity. Mirror upstream's own positioning: authorization and lawful use are assumed prerequisites.

Artifact Supply Chain¶

ecli consumes either locally compiled packages or remote ones:

$ sudo ./ecli run ghcr.io/eunomia-bpf/execve:latest

Remote mode executes third-party-compiled bytecode under your kernel account. For anything security-sensitive:

prefer compiling locally from the repository you inspected (ecc minimal.bpf.c) over pulling ghcr.io images;
treat --no-cache refetches like dependency updates — review what changed;
the OCI contents include exported event headers/config JSON; inspect package.json alongside the .bpf.c it claims to match.

This follows the vault-wide reference-first rule: the repository source above is the trusted origin for any tool behavior described in these notes.

Lifecycle Residue¶

Lesson 28 teaches that pinned, linked-away-from-process programs can outlive their launcher. After experiments, check residue rather than assuming teardown:

sudo bpftool prog show
sudo bpftool map show
sudo rm -f /sys/fs/bpf/<pinned-path>   # only pins you created

Orphaned kprobes silently keep collecting — a privacy leak in exactly the spirit the tracing lessons demonstrate.

Questions¶

Do the org's newer BPF-token features (features/bpf_token lesson) map onto a delegated least-privilege workflow for classroom/shared-lab settings?
Is there upstream guidance yet for verifying signature/provenance of OCI-published compiled tools?