Lion Cipher Lab

Enforce runtime policy with a BPF LSM program (deny an action from inside the kernel)

Why it matters

In the seccomp lab you built a wall at the syscall boundary — and hit its ceiling on purpose: seccomp sees a syscall NUMBER and the scalar register arguments, but it deliberately cannot look at the file a path points to, so it can allowlist the open() syscall yet never say 'open anything EXCEPT this one secret file.' That 'which object' question is exactly what real security policy is made of, and it is why the kernel grew a second, richer enforcement layer. The Linux Security Modules (LSM) framework sprinkles HOOKS through the kernel at every security-relevant decision — a file is about to…

What you'll learn

Steps in this lab

  1. eBPF, LSM, and the one idea this lab is built on
  2. Gate first: does this kernel actually support BPF-LSM? (be honest before you invest)
  3. Enable the BPF LSM: add 'bpf' to the lsm= boot parameter and reboot
  4. Install the toolchain and generate vmlinux.h (CO-RE)
  5. Pick the target: create a protected file and record its inode
  6. Write the BPF LSM program: attach to lsm/file_open and return -EPERM
  7. Load and attach it: prove the block (the file now refuses to open)
  8. Detach it: prove the action works again (enforcement is live only while attached)
  9. The verifier and the hard constraints (this is the advanced part)
  10. The judgment: BPF-LSM vs seccomp vs SELinux/AppArmor — and who productionizes it

Open the full interactive lab →