What role do AppArmor and SELinux play in confining containers, how do they differ from Linux capabilities and syscall filtering, and how do you tell when one of them is causing a failure?

## Where MAC sits in the stack A containerised process passes several independent gates: 1. **Discretionary access control (DAC)** — the classic uid/gid and file mode checks. "Discretionary" because the file's owner can change them. 2. **Capabilities** — is this process permitted to perform this *privileged operation class*? 3. **seccomp** — is this *syscall number* allowed at all? 4. **Mandatory access control (MAC)** — does policy allow *this subject* to act on *this object*? Set by an administrator, and not overridable by the file owner or by root. MAC is the only one of the four that reasons about the object being touched. seccomp cannot (it cannot dereference pointers to read a path); capabilities are coarse (`CAP_DAC_OVERRIDE` is all-or-nothing). So MAC is what expresses "this container may read its own volume and nothing else on the host". ## AppArmor AppArmor policies are path-based and attached to executables or applied by the runtime. Docker generates a profile named `docker-default` and applies it to every container on systems where AppArmor is active. Its restrictions include: - Deny writes to `/proc/sys/**` (blocking the `core_pattern` escalation trick) and to most `/sys` paths. - Deny `mount` and `umount` operations. - Deny `ptrace` and signals across the container boundary. - Deny raw access to kernel interfaces such as `/proc/kcore`, `/proc/sysrq-trigger`. Custom profiles are written in AppArmor's own language, loaded on the *host* with `apparmor_parser -r`, and selected per container with `--security-opt apparmor=profile-name`. That host-side load step is the operational catch: the profile must exist on every node before a workload referencing it starts, otherwise the container fails to start. Because the rules are path-based, an AppArmor profile is readable and easy to reason about — and brittle when paths change, e.g. after a bind-mount is moved. ## SELinux SELinux labels every process and every object with a context of the form `user:role:type:level`. The enforcement rule is type-based: policy states which *source types* may perform which operations on which *target types*. For containers the key types are `container_t` (the process) and `container_file_t` (files it may access). A host file labelled `etc_t` or `admin_home_t` is simply not accessible to `container_t`, no matter what the file mode says or whether the process is root — which is precisely why SELinux blunts many escape and host-file-read scenarios. On top of type enforcement, containers use **MCS** (multi-category security): each container is assigned a unique category pair such as `s0:c123,c456`, and its files are labelled with the same pair. Two containers both running as `container_t` therefore still cannot read each other's files. This is the mechanism that turns SELinux from "containers vs host" into "container vs container" isolation. **Bind mounts and relabelling.** A host directory has whatever label it had; a container cannot read it. Docker's volume suffixes solve this: - `-v /host/data:/data:z` relabels the content `container_file_t` with a *shared* category, so several containers can use it. - `-v /host/data:/data:Z` relabels it with the container's *private* category — exclusive access. Use `:Z` unless sharing is intended, and be careful: relabelling a directory like `/home` or `/var` recursively can break the host badly. `--security-opt label=disable` turns SELinux confinement off for one container; treat that like `seccomp=unconfined`. ## Diagnosing MAC denials The signature is a mismatch between symptom and evidence. Inside the container you see `Permission denied` on a file that appears world-readable with the correct uid — DAC clearly permits it. The denial is logged on the **host**: - AppArmor: `dmesg | grep -i apparmor` or `journalctl -k`, lines containing `apparmor="DENIED"` with `operation=`, `profile=docker-default`, `name=<path>`. - SELinux: `ausearch -m AVC -ts recent` or `journalctl -t setroubleshoot`; `audit2allow` can suggest a policy delta (review it, do not paste it blindly). A quick triage: run the workload once with `--security-opt apparmor=unconfined` or `--security-opt label=disable` **in a test environment**. If the failure disappears, MAC is the layer; if not, look at capabilities (EPERM on a privileged operation) or seccomp (EPERM/SIGSYS on a syscall). Because all three can surface as `EPERM`, having a deterministic order to test them is what makes this tractable under incident pressure. SELinux also offers `permissive` mode — policy evaluated and denials logged but not enforced — which is the right way to gather a complete denial set before writing policy, and much better than disabling it. ## Practical posture Keep the runtime default profile on (`docker-default` / `container_t`) for everything. Write custom profiles only where a workload genuinely needs a narrower or slightly wider policy, keep them in version control, and distribute them with the node image rather than by hand. Never disable MAC as a fix for a startup failure — the denial message names the exact object, which is usually enough to correct a mount label or a path. And record which workloads run unconfined, because that list is a standing risk register, not a configuration detail.