Lion Cipher Lab
Enforce runtime policy with a BPF LSM program (deny an action from inside the kernel)
- Cyber / Security Engineer
- Advanced
- ~90 min
- Free · no account required
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
- what eBPF is: safe, verified programs the kernel runs at defined hook points without loading a kernel module
- what an LSM (Linux Security Module) is and what an LSM HOOK is: a policy checkpoint the kernel already placed at a security decision
- the difference that makes BPF-LSM powerful: the hook sees rich CONTEXT (the struct file, the inode, the cred), not just a syscall number
- gating on kernel support HONESTLY before you invest: CONFIG_BPF_LSM=y and 'bpf' present in /sys/kernel/security/lsm
- adding 'bpf' to the lsm= boot parameter in GRUB and rebooting when your distro ships it off by default
- CO-RE and vmlinux.h: writing one portable BPF program that reads kernel structs correctly across kernel versions
- writing a BPF program attached to lsm/file_open that inspects the target inode and returns -EPERM to DENY the open
- loading it with a libbpf skeleton (or a minimal bpftool path) and PROVING the block: the protected action now fails 'Operation not permitted'
- detaching the program and proving the action works again — enforcement is live only while the program is attached
- the verifier constraints on an LSM program: you may READ context and RETURN an int; sleepable vs non-sleepable hooks; you can only enforce where a hook EXISTS
Steps in this lab
- eBPF, LSM, and the one idea this lab is built on
- Gate first: does this kernel actually support BPF-LSM? (be honest before you invest)
- Enable the BPF LSM: add 'bpf' to the lsm= boot parameter and reboot
- Install the toolchain and generate vmlinux.h (CO-RE)
- Pick the target: create a protected file and record its inode
- Write the BPF LSM program: attach to lsm/file_open and return -EPERM
- Load and attach it: prove the block (the file now refuses to open)
- Detach it: prove the action works again (enforcement is live only while attached)
- The verifier and the hard constraints (this is the advanced part)
- The judgment: BPF-LSM vs seccomp vs SELinux/AppArmor — and who productionizes it