LSM & mandatory access control

Where SELinux/AppArmor and BPF-LSM hook in.

Linux Security Modules are the kernel’s framework for mandatory access control, and understanding them explains both how SELinux/AppArmor confine containers and how modern eBPF tools hook the same decision points to enforce policy.

Where LSM sits

Standard Linux permissions (DAC — discretionary access control) let the owner of a resource decide access. LSM adds a second, mandatory layer: at hundreds of security-relevant points in the kernel — opening a file, executing a binary, using a capability — an LSM hook asks a policy module "is this allowed?", and the action proceeds only if both DAC and the LSM agree. This is why a process running as root inside a container can still be blocked from an action: the LSM policy denies it regardless of the DAC permission.

# Every guarded action passes through DAC then the LSM hook:
#
#   process wants to exec /bin/sh
#        │
#        ├─ DAC check      (file permissions / owner)      → allow
#        └─ LSM hook       (SELinux/AppArmor/BPF-LSM)       → deny
#        ⇒ action DENIED — mandatory policy overrides the permission
#
# Which LSMs are active on this kernel:
cat /sys/kernel/security/lsm     # e.g. capability,lockdown,yama,apparmor,bpf

BPF LSM: policy as eBPF

The BPF LSM (available on modern kernels) lets you attach eBPF programs to LSM hooks, so runtime security tools can make allow/deny decisions in the kernel using the same framework as SELinux and AppArmor — but driven by dynamic, Kubernetes-aware policy. This is the mechanism behind in-kernel enforcement: instead of alerting a userspace agent after a syscall completes, a BPF-LSM program can deny the operation synchronously. It is the bridge between eBPF observability and true prevention.