Security & LSM
Enforce and observe security with LSM hooks and signal programs — connection control, tamper detection, and lab-only offense to understand defense.
BPF LSM: from observing to deciding
The shift from watching the kernel to mediating it: attach a BPF program to an LSM hook whose return value allows (0) or denies (-EPERM) an operation, and confine a single container's outbound connections by cgroup without touching the host.
Signal programs: reacting with force
The other enforcement style: instead of denying a syscall at an LSM hook, react to one. A tracepoint on execve matches a forbidden binary and calls bpf_send_signal(SIGKILL) to kill the process before it runs — a 'signal program', lab-only offense that illuminates defense.
Hiding a process (lab-only offense)
Understand rootkit-style eBPF by building one in the lab: rewrite the getdents64 buffer with bpf_probe_write_user so a chosen PID vanishes from /proc — invisible to ps and ls — then learn exactly how a defender detects the tampering.
Protecting a file with LSM
The defensive counterpart to the offense chapter: an LSM program on inode_permission that denies write access to one protected file by inode — making it read-only even for root — and a first look at reading a kernel struct field from an LSM program (with CO-RE deferred to Part 9).
Faking your way to root (lab-only offense)
The third lab-only offense: intercept the read() a privileged process makes and rewrite the bytes it gets back. When sudo reads /etc/sudoers, inject a line granting full privileges — the file on disk untouched — to see how read-buffer tampering escalates, and how to detect it.
A security sensor: telemetry and shielding
Close the security part by building the sensor layer of a runtime-security tool: several attacker-relevant hooks (execve, ptrace, setuid) feeding one structured event stream to Grafana, with a clear path from observing to shielding.