Container Security Model: Namespaces, Capabilities, Seccomp, AppArmor, SELinux, Devices, and Privilege Boundaries: Concepts, Architecture, and Mental Model

1. The practical problem: isolation is not the same as trust

Docker gives a process a distinct view of resources through namespaces, constrains resources with cgroups, and applies additional kernel authorization controls. Those mechanisms reduce the process’s authority, but none of them turns an arbitrary workload into a separate physical machine. A workload that receives broad capabilities, host namespaces, powerful devices, writable host paths, or Docker daemon access crosses important trust boundaries even if its prompt still looks like a container shell.

Chapter 24 separated process state from health and recovery. This chapter applies the same evidence-first discipline to security: first determine what identity and authority the process already has, then remove only what is unnecessary.

2. Mental model: layered authority from kernel to application

The host kernel is the common enforcement point. Namespaces control which resources a process can see. UID/GID and filesystem ownership determine normal identity checks. Linux capabilities split traditional root powers into narrower privileges. Seccomp filters syscall entry. AppArmor or SELinux can constrain permitted objects/actions through Linux Security Module policy. Device access, mounts, network modes, and daemon/API access can then expand or narrow the practical attack surface.

  flowchart TD
    A[Host kernel] --> B[Namespaces + cgroups baseline]
    B --> C[UID/GID identity]
    C --> D[Linux capability set]
    D --> E[Seccomp syscall filter]
    E --> F[AppArmor or SELinux policy]
    F --> G[Devices + mounts + network namespace]
    G --> H[Application process]
    H --> I[Host/external side effects allowed only by accumulated authority]
            

3. Namespaces change visibility, not kernel ownership

Typical Linux containers use separate PID, mount, IPC, UTS, and network namespaces, with additional namespace behavior depending on daemon/runtime configuration. A container PID namespace can make the application appear as PID 1 inside the container while the host sees a different PID. Sharing a host namespace deliberately collapses one of those isolation layers, so host PID/network namespace choices are security architecture decisions rather than debugging conveniences.

docker info --format '{{json .SecurityOptions}}'
docker inspect CONTAINER --format 'pid_mode={{.HostConfig.PidMode}} network_mode={{.HostConfig.NetworkMode}} ipc_mode={{.HostConfig.IpcMode}}'
docker inspect CONTAINER --format 'host_pid={{.State.Pid}} user={{json .Config.User}}'

4. Runtime user and host authority are different questions

Running as a non-root user reduces what the application can do through normal Unix permissions and often reduces the impact of compromise. But “UID 1000 inside” does not by itself answer how that UID maps to the host, whether user namespaces are enabled, which supplementary groups or capabilities are present, which host files are mounted, or whether a device/API grants separate authority. Chapter 26 explores rootless Docker and user namespaces in depth; here they are treated as additional layers, not substitutes for the rest.

5. Linux capabilities: split root authority into named privileges

Docker starts ordinary Linux containers with a default subset of capabilities rather than every capability. Controls such as --cap-drop and --cap-add change that set. The safest design begins with the operation the application must perform, removes unneeded capabilities, and adds back only the narrow capability proven necessary. Broad powers such as CAP_SYS_ADMIN cover many kernel operations and therefore deserve exceptional scrutiny.

6. Seccomp filters syscall entry

Docker’s built-in seccomp profile is applied on supported Linux hosts unless configuration changes it. Current Docker documentation describes it as an allowlist-style policy that returns an error for blocked syscalls. A “permission denied” result can therefore be deliberate sandbox behavior rather than a filesystem bug. Do not leap from one denied syscall to disabling the filter; identify the syscall and why the application needs it.

7. AppArmor and SELinux add mandatory access control

On AppArmor systems Docker normally uses a generated docker-default container profile. On SELinux systems, Docker integration depends on the daemon/distribution policy being enabled and correctly labeled. These policies can deny operations even when Unix mode bits and capabilities appear permissive. Their audit logs are therefore important first-failure evidence. Do not disable an LSM merely to make a workload run.

8. Read-only rootfs, tmpfs, mounts, devices, and sockets shape real authority

A read-only root filesystem narrows mutation but applications still need selected writable paths for temporary files, sockets, or caches; targeted tmpfs mounts can provide those paths without making the entire image filesystem writable. Device mappings expose host-backed interfaces. Bind mounts can expose host data. Access to the Docker API or socket effectively delegates control over the daemon and must be treated as high authority. Each is a separate design decision visible in docker inspect.

9. Read-only baseline inspection before hardening

docker version
docker context show
docker info --format '{{json .SecurityOptions}}'

docker inspect CONTAINER --format 'user={{json .Config.User}} readonly={{.HostConfig.ReadonlyRootfs}} privileged={{.HostConfig.Privileged}}'
docker inspect CONTAINER --format 'cap_add={{json .HostConfig.CapAdd}} cap_drop={{json .HostConfig.CapDrop}}'
docker inspect CONTAINER --format 'security_opt={{json .HostConfig.SecurityOpt}} devices={{json .HostConfig.Devices}}'
docker inspect CONTAINER --format '{{json .Mounts}}'

10. Authority-expanding settings are architectural exceptions

11. DevOps connection: reproducibility includes the security boundary

Two containers running the same image digest are not equivalent if one has a different user, capability set, seccomp/LSM policy, namespace mode, device list, or host mount. Record the exact image identity and runtime security configuration together. That makes the boundary auditable and makes rollback or incident comparison meaningful.

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.