How do Seccomp and AppArmor/SELinux profiles restrict container system calls?
❓ Interview Prompt: Explain Seccomp syscall filtering, AppArmor MAC profiles, and Linux capability dropping for defense-in-depth container security.
Defense-in-depth container security uses multiple layers of Linux security mechanisms:
1. Linux Capabilities (Coarse-Grained):
The root user's privileges are split into ~40 capabilities (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN). Drop capabilities containers don't need:
```yaml
securityContext:
capabilities:
drop: ["ALL"]
add: ["NET_BIND_SERVICE"] # only if binding port < 1024
```
2. Seccomp (Fine-Grained Syscall Filtering):
Seccomp (Secure Computing Mode) uses BPF to filter which Linux system calls a container process can make. The default Docker seccomp profile blocks ~44 dangerous syscalls (ptrace, mount, kmod, etc.).
Custom profiles block additional syscalls not needed by the application.
3. AppArmor (Mandatory Access Control):
AppArmor profiles define what files, capabilities, and network access a process is allowed — enforced by the kernel's LSM (Linux Security Module). Docker applies a default AppArmor profile to all containers.
4. SELinux (RedHat Alternative):
SELinux provides MAC through labels on files and processes — used on RHEL/Fedora instead of AppArmor.
Code Implementation Example
# Kubernetes Pod with hardened security context
apiVersion: v1
kind: Pod
spec:
securityContext:
runAsNonRoot: true # refuse to run as root
runAsUser: 1001 # explicit UID
runAsGroup: 1001
fsGroup: 1001 # file ownership for mounted volumes
seccompProfile:
type: RuntimeDefault # use node's default seccomp profile
# OR custom profile:
# type: Localhost
# localhostProfile: profiles/my-app.json
containers:
- name: api
image: myapp:v1.2.3
securityContext:
allowPrivilegeEscalation: false # block setuid/setgid binaries
readOnlyRootFilesystem: true # container can't write to /
capabilities:
drop:
- ALL # drop ALL capabilities
add:
- NET_BIND_SERVICE # re-add only what's neededLayer security: drop ALL capabilities + add only needed ones, enable readOnlyRootFilesystem, apply RuntimeDefault seccomp, and run as non-root UID — four independent security layers.