Week 16 - LSM for Containers: SELinux and AppArmor¶
16.1 Conceptual Core¶
- SELinux and AppArmor add a third confinement layer (after capabilities and seccomp): what objects (files, sockets) the process may access.
- Most container runtimes apply a generic profile by default:
- SELinux:
container_ttype, with category-based isolation (multi-category security, MCS) so two containers on the same host can't access each other's files even if they share a UID. - AppArmor:
runtime/default(a path-based profile generated by Docker/podman). - Custom profiles tighten further; this is what hardened multi-tenant container hosts (OpenShift, Bottlerocket) ship.
16.2 Mechanical Detail¶
- SELinux for containers:
- Each container gets a unique MCS category, applied via the
:s0:cN,cMsuffix on the type. - Policy:
container.tefromcontainer-selinuxpackage. - Volume mounts: must be relabeled (
:Zmount option) or marked:z(shared label)-otherwise SELinux denies access. - Debugging:
ausearch -m AVC -ts recent. - AppArmor for containers:
- Profile in
/etc/apparmor.d/. Load withapparmor_parser -r. - Apply with - -security-opt apparmor=my-profile`.
- Tooling:
aa-genprof,aa-logprofto iterate.
16.3 Lab-"MAC Per Workload"¶
- On RHEL/Fedora: write a custom SELinux policy module for one service. Test enforcement.
- On Ubuntu/Debian: write an AppArmor profile for the same service. Test enforcement.
- Document the comparative effort and expressivity.
16.4 Hardening Drill¶
- Verify your hosts run with LSM in enforcing mode (
getenforce,aa-status). Permissive is for development only.
16.5 Production Readiness Slice¶
- Wire LSM denial alerts: ship
audit.log(SELinux) orkern.log(AppArmor) to your central log aggregator; alert on AVCs from prod containers.
Month 4 Capstone Deliverable¶
A container-security/ workspace:
1. image-audit/ - week 13's audit findings + remediation.
2.cap-diet/ - week 14's capability matrix per service.
3. seccomp-profiles/ - week 15's per-service profiles, CI-validated.
4.lsm-profiles/ - week 16's SELinux + AppArmor profiles.
A THREAT_MODEL.md covering: what the model isolates against, what it doesn't, what to use instead for the gaps.