Container Security Model: Namespaces, Capabilities, Seccomp, AppArmor, SELinux, Devices, and Privilege Boundaries: Configuration, Design Choices, and Tradeoffs

1. Default seccomp versus a custom profile

The built-in profile tracks Docker’s runtime expectations and current hardening. A custom profile can solve a legitimate compatibility requirement or enforce a narrower application policy, but it creates maintenance responsibility: architecture differences, new application versions, kernel behavior, and Docker security updates must all be reviewed. Prefer the default unless there is evidence for a deliberate change.

2. Capability allowlist versus default capability set

A practical hardening path is to test with cap-drop=ALL and then add back the smallest capability set required. This creates an explicit allowlist and makes authority changes visible in code review. The cost is compatibility work for software that silently assumes traditional root privileges. Treat capability additions as documented requirements with a reproducer.

3. LSM policy: host/distribution context matters

AppArmor and SELinux solve related mandatory-access-control problems through different policy models and are integrated differently by distributions. Do not ship one host’s policy assumption as if it were portable everywhere. Instead, document the required host control, provide a safe baseline on unsupported platforms, and test enforcement where the production environment actually runs.

4. Read-only filesystem versus writable runtime state

A read-only root filesystem makes unauthorized or accidental mutation harder and exposes software that improperly writes into its installation tree. It works best when writable state is classified: ephemeral state goes to tmpfs, persistent state goes to an explicit managed volume, and configuration comes from declared runtime inputs. This also improves incident reasoning because writable surfaces are enumerable.

5. Rootless Docker and user namespaces are additional layers

User namespaces remap container identities; rootless Docker runs the daemon and containers without a rootful daemon. Both can reduce host impact from certain compromise paths, but each changes networking, storage, device, and privileged-operation assumptions. They do not make broad mounts, weak application authorization, or exposed credentials safe. Chapter 26 treats these tradeoffs in depth.

6. Shared kernel versus stronger VM/sandbox boundary

For mutually hostile or strongly isolated tenants, the shared host kernel can be the wrong trust boundary even when container controls are hardened. A microVM, VM, sandboxed runtime, or dedicated host may provide a more appropriate isolation layer. This costs density, startup time, operational complexity, or hardware resources, but it changes the failure domain rather than only tightening one container policy.

7. Decision table: choose the control from the failure boundary

8. Worked scenario: image-processing API

Assume an API reads an uploaded image, writes temporary conversion output, and returns the result. It needs no host devices, no host namespace, no persistent rootfs writes, and no Docker daemon access. A justified baseline is a non-root UID, dropped capabilities, default seccomp/LSM policy, read-only rootfs, and a bounded tmpfs for temporary conversion. If the conversion library later needs one blocked syscall, preserve the failing syscall evidence and review the narrowest policy change instead of expanding unrelated permissions.

9. Portability and Docker Desktop

Docker Desktop runs Linux containers inside a managed Linux VM. The effective kernel, cgroup, namespace, AppArmor/SELinux availability, device surface, and host filesystem path semantics therefore differ from a native Linux Engine. Record the daemon context and platform before claiming that a host security control is active.

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.