Container Runtime Hardening

Seccomp Profiles: Filtering Syscalls

Every process running inside a container makes system calls (syscalls) to the kernel — opening files, creating network sockets, spawning processes, changing permissions. A typical application uses only a fraction of the 300+ syscalls available on Linux. The syscalls your application never uses are an attack surface: if an attacker exploits a vulnerability, they can only use syscalls that are permitted.

Seccomp (Secure Computing Mode) is a Linux kernel feature that filters which syscalls a process can invoke. Docker and containerd apply a default seccomp profile that blocks known-dangerous syscalls, but you can create custom profiles for finer control.

How seccomp works

A seccomp profile is a JSON file that defines which syscalls are allowed, denied, or handled with specific actions:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod", "fchmod", "fchmodat"],
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "names": ["mount", "umount2"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

The actions:

• SCMP_ACT_ALLOW: Permit the syscall
• SCMP_ACT_ERRNO: Block the syscall and return an error (the application gets EPERM)
• SCMP_ACT_KILL: Kill the process that attempts the syscall
• SCMP_ACT_LOG: Log the syscall attempt (useful for building profiles)

Building a custom seccomp profile

The most practical approach is to start with the default Docker profile and add restrictions:

# Run a container with syscall logging to build a custom profile
docker run --security-opt seccomp=unconfined \
  --security-opt seccomp-log \
  myapp:latest 2>&1 | grep "syscall"

# Or use strace to capture syscalls
strace -f -e trace=all python3 app.py 2>&1 | grep "^(" | sort -u

Then create a profile that allows only the syscalls your application actually uses:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "names": [
        "accept", "accept4", "access", "arch_prctl", "bind",
        "brk", "clock_gettime", "close", "connect", "epoll_create1",
        "epoll_ctl", "epoll_wait", "execve", "exit_group", "fstat",
        "futex", "getcwd", "getdents64", "getpeername", "getrandom",
        "getsockname", "getsockopt", "ioctl", "listen", "lseek",
        "madvise", "mmap", "mprotect", "munmap", "newfstatat",
        "openat", "poll", "read", "readlink", "recvfrom",
        "rt_sigaction", "rt_sigprocmask", "sendto", "setitimer",
        "setsockopt", "shutdown", "sigaltstack", "socket", "stat",
        "sysinfo", "tgkill", "time", "uname", "wait4", "write",
        "writev"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

This profile uses defaultAction: SCMP_ACT_ERRNO (deny by default) and explicitly allows only the syscalls the application needs. Any syscall not in the list returns EPERM.

Applying seccomp profiles

# Docker
docker run --security-opt seccomp=/path/to/profile.json myapp:latest

# Kubernetes — via securityContext (Kubernetes 1.24+)
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/myapp.json
  containers:
  - name: app
    image: myapp:latest

The default Docker seccomp profile

Docker's default profile blocks approximately 44 syscalls that are known to be dangerous or unnecessary, including:

• mount, umount2 — filesystem mounting
• reboot — system reboot
• kexec_load — kernel loading
• open_by_handle_at — can bypass file permissions
• ptrace — process debugging (used in container escapes)

The default profile is a good starting point, but custom profiles provide defense in depth by restricting to only what your specific application needs.

Linux Capabilities and Filesystem Restrictions

Linux capabilities split the privileges of the root user into distinct units. Instead of running as root (which has all capabilities), a process can be granted only the specific capabilities it needs. Containers inherit a default set of capabilities from the runtime — most of which are unnecessary for typical applications.

The default capability set and why it's too broad

Docker's default capability set includes 14 capabilities. A typical web application needs almost none of them:

Dropping all capabilities

The most secure approach is to drop all capabilities and add back only what's needed:

# Kubernetes pod spec
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE  # Only if binding to port 80/443

# Docker
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE myapp:latest

If your application doesn't bind to ports below 1024, you don't even need NET_BIND_SERVICE. Drop everything.

Read-only root filesystem

A read-only root filesystem prevents any process from writing to the container's filesystem. This stops attackers from:

• Downloading and executing malicious binaries
• Modifying application code or configuration
• Writing persistence mechanisms (cron jobs, startup scripts)
• Tampering with or deleting logs

# Kubernetes
securityContext:
  readOnlyRootFilesystem: true

# Docker
docker run --read-only --tmpfs /tmp --tmpfs /var/tmp myapp:latest

Applications that need to write files should use:

• emptyDir volumes for temporary files (Kubernetes)
• tmpfs mounts for writable directories (Docker)
• Persistent volumes for data that must survive container restarts

Resource limits

Resource limits prevent a compromised container from consuming all host resources:

# Kubernetes
resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Without limits, a compromised container can:

• Consume all available memory (OOM killer terminates other containers)
• Use all CPU cycles (starving other workloads)
• Fill the disk with logs or downloaded files
• Open thousands of network connections (exhausting file descriptors)

Putting it all together: a hardened pod spec

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 999
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

This pod spec implements every runtime hardening control: non-root user, seccomp, no privilege escalation, read-only filesystem, dropped capabilities, and resource limits. An attacker who compromises this container has minimal capabilities, cannot write files, cannot escalate privileges, and cannot consume excessive resources.