Containers should not execute mount system calls
Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel,
n'hésitez pas à nous contacter.
Security recommendation
| Impact | Remediation complexity | Severity | Recommended value |
|---|
| 4 | 3 | 4 | Containers should not execute mount system calls |
Containers should not be able to execute mount system calls unless explicitly required for legitimate operations. Mount operations in containers indicate potentially dangerous security configurations that weaken container isolation.
Compliance
Documentation
The mount system call allows processes to attach filesystems and devices to the system’s directory tree.
Prerequisites
- You must have administrative access to the container runtime environment
- Access to container orchestration configuration (Kubernetes, Docker Compose, etc.)
Step-by-step guide
Step 1: Identify the Container and Configuration
Review the Finding and inspect the container’s security configuration:
# List running containers
docker ps
# Check AppArmor profile (should NOT be "unconfined" or empty)
docker inspect <container_id> | jq '.[0].AppArmorProfile'
# Inspect security options
docker inspect <container_id> | jq '.[0].HostConfig.SecurityOpt'
Step 2: Verify Legitimate Requirement
Determine if mount capability is actually needed for the container’s function. In most cases, it is not required.
Step 3: Remove Dangerous Configuration
Stop and restart the container with proper security settings:
# Stop and remove the vulnerable container
docker stop <container_id> && docker rm <container_id>
# Restart with default AppArmor profile (remove --security-opt apparmor=unconfined)
docker run --name <container_name> <image>
# Or specify a custom restrictive profile
docker run --security-opt apparmor=<custom-profile> --name <container_name> <image>
For Kubernetes deployments, update pod specifications to use proper AppArmor profiles:
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
annotations:
# Use runtime/default instead of unconfined
container.apparmor.security.beta.kubernetes.io/<container-name>: runtime/default
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
For Kubernetes 1.25+, enforce Pod Security Standards at the namespace level:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
Step 6: Verify and Audit
Confirm the remediation was successful:
# Verify AppArmor profile is applied (should show "docker-default" or custom profile)
docker inspect <container_id> | jq '.[0].AppArmorProfile'
# Verify mount is now denied
docker exec <container_id> mount /dev/sdb1 /mnt # Should fail
# Audit infrastructure as code for similar misconfigurations
grep -r "apparmor=unconfined" .
grep -r "apparmor.*unconfined" k8s/