Closing the BPF map permission loophole
summary
A bug allows a process with CAP_BPF bypass to modify maps opened read-only: a loaded BPF program can call map_update_elem with a read-only fd, pinning a read-only map yields a read-write fd, and map-in-map tricks also escalate access. The uploader tested this with the tubular codepath and syscall flows on bpffs. Two fixes are proposed: refuse non-read-only fds in the verifier or extend verifier state with a BPF type flag that tracks value mutability, plus tightening pin/chmod semantics to prevent chmod-based permission escalation.
AI-written summary · about
chapters (4)
- 0:00Start
- 10:21Ways to restrict modifications of BPF maps
- 20:28Reason: verifier doesn't check per fd permissions
- 25:48Fix #2: adjust permissions + prevent chmod() escalation
related talks
30mBPF for Security and LSM updates
25mDiscussion: What's next for BPF Signing
36mHow to Safely Restrict Access to Files in a Programmatic Way with Landlock?
20mEPF: Evil Packet Filter
27mLSM BPF Change Everything
57mBPF and Security. Friends and Foes
01h 03mBPF and Spectre: Mitigating transient execution attacks
27mBPF LSM - Updates and What next?