Container Security Model: Namespaces, Capabilities, Seccomp, AppArmor, SELinux, Devices, and Privilege Boundaries: Diagnostics, Failure Modes, Security, and Performance

1. Evidence-first security diagnostic sequence

2. Intentionally broken example: writable-path assumption

This disposable container deliberately tries to write under /var/lib/app while the root filesystem is read-only. The failure is preserved. The repair is a narrow tmpfs at the required path—not added capabilities, not disabled security policy.

docker rm -f dkr25-broken dkr25-fixed 2>/dev/null || true

docker run \
  --name dkr25-broken \
  --user 65534:65534 \
  --cap-drop ALL \
  --security-opt no-new-privileges=true \
  --read-only   alpine:3.22 sh -c 'mkdir -p /var/lib/app && echo state >/var/lib/app/state'   >dkr25-broken.stdout 2>dkr25-broken.stderr || true

docker inspect dkr25-broken \
  --format 'exit={{.State.ExitCode}} readonly={{.HostConfig.ReadonlyRootfs}} user={{json .Config.User}} cap_drop={{json .HostConfig.CapDrop}} security_opt={{json .HostConfig.SecurityOpt}}'   | tee dkr25-broken.inspect.txt
cat dkr25-broken.stderr

# Repair only the required writable path.
docker run \
  --rm \
  --name dkr25-fixed \
  --user 65534:65534 \
  --cap-drop ALL \
  --security-opt no-new-privileges=true \
  --read-only \
  --tmpfs /var/lib/app:rw,nosuid,nodev,size=8m,uid=65534,gid=65534   alpine:3.22 sh -c 'echo state >/var/lib/app/state && cat /var/lib/app/state'

3. Missing capability versus ordinary file permission

Do not infer a capability problem from every EPERM. First inspect the target object’s ownership/mode, runtime UID/GID, requested capabilities, and filesystem mount mode. Only after a reproducer shows a privileged kernel operation should a capability change be considered. If one is needed, add the narrow capability and keep all others dropped.

4. Seccomp denial: identify the syscall before changing policy

Seccomp commonly surfaces as an operation denied by the kernel. Capture the application trace/log and, where available, kernel/audit evidence. Check whether the syscall is documented as blocked and whether the application can avoid it. A reviewed custom profile is a last-mile compatibility tool, not a generic fix. Current Docker security guidance explicitly warns against disabling seccomp to work around the 2026 socket hardening issue.

5. AppArmor/SELinux denial: use audit evidence

LSM denials often include policy/profile and target-object details in host audit logs. Preserve those records before changing labels or profiles. Correct the label/policy for the intended resource or redesign the access. Do not switch the host to an unconfined policy merely to make the error disappear.

6. Host namespace sharing changes the diagnosis and the threat boundary

If a workload requires seeing host processes or using the host network stack, first ask why. Host namespace sharing is not just “more connectivity” or “better debugging”; it removes an isolation layer. Prefer dedicated diagnostic tooling, read-only telemetry, or a separate privileged operations plane rather than granting ordinary application containers host-wide visibility.

7. Writable host mounts and daemon/API exposure are high-authority paths

A writable bind mount can let a container change host data in that path. Docker daemon/API access can let a client create containers and request host resources, making it an administrative boundary. These should not be used as convenient fixes for file access or build tooling. If automation truly requires daemon operations, isolate the automation identity and service from untrusted application workloads.

8. “Non-root” can still carry dangerous authority

A non-root UID can still be connected to powerful groups, devices, mounts, network namespaces, or APIs. Conversely, UID 0 inside a user namespace may map to an unprivileged host UID. Security review must therefore describe the full mapping and authority set rather than using a single “root/non-root” label.

9. Security and performance: measure, do not assume

Default namespace, capability, seccomp, and LSM enforcement usually costs far less than the risk of removing the boundary. If a workload shows measurable overhead, benchmark the exact operation and preserve profiling evidence. Do not turn off a protection based on generic claims. Stronger VM/sandbox isolation can have larger resource costs; that is an architectural tradeoff tied to the threat model.

10. Troubleshooting shortcuts that hide the cause

11. Cleanup the broken-example resources

docker rm -f dkr25-broken dkr25-fixed 2>/dev/null || true
rm -f dkr25-broken.stdout dkr25-broken.stderr dkr25-broken.inspect.txt

Knowledge check

Official references and version notes

• Docker Engine security — daemon trust, kernel isolation, user namespaces, and host-hardening context.
• Seccomp security profiles for Docker — built-in profile behavior, blocked syscall rationale, and custom profile mechanics.
• AppArmor security profiles for Docker — generated docker-default profile and custom-policy workflow.
• docker container run reference — capabilities, devices, read-only rootfs, security options, user, namespaces, and resource/security controls.
• Compose service capability controls — cap_add and cap_drop.
• Compose service security_opt — including no-new-privileges and LSM labels.
• Compose read_only — read-only root filesystem semantics.
• Docker tmpfs mounts — ephemeral writable memory-backed state.
• Docker Engine 29 release notes — current release baseline and 2026 security changes.