The ‘sec____’ ignored in Ops with Docker!!

Imagine you’re deploying a web application in a container. This web application doesn’t need access to low-level system operations like managing network interfaces, setting kernel parameters, or executing privileged operations.

By default, Docker containers run with access to many system calls, some of which may be unnecessary or even dangerous from a security perspective.
For example, the mknod system call allows a process to create device files, which could be exploited to create malicious device files. Similarly, pivot_root can alter the root file system, which could be used for a container escape attempt.

By default, Docker containers run as the root user (UID 0), and it’s recommended to run containers as a non-root user using the USER directive in your Dockerfile to switch to a specific user before the ENTRYPOINT or CMD.

But, there is another aspect. Even running them as non-root user can be vulnerable in many cases.

This brings us to use ‘seccomp’ the most ignored component but with zero to no hassle it brings us huge upside.

The official docker documentation has it as.
“Secure computing mode (seccomp) is a Linux kernel feature. You can use it to restrict the actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. You can use this feature to restrict your application's access.”

Out of more than 300+ syscalls, using just the default seccomp profile (it’s used by default!!) disables around 44 system calls.

While it’s not recommend to change the default seccomp profile, one override it with the --security-opt option.

docker run --rm \
             -it \
             --security-opt seccomp=/path/to/seccomp/customseccompprofile.json \
             hello-world

And if you are wondering about your workload running in k8s, we have options there as well.
The official documentation suggests, there are four ways to specify a ‘seccomp’ profile for a pod:

• for the whole Pod using spec.securityContext.seccompProfile

• for a single container using spec.containers[*].securityContext.seccompProfile

• for an (restartable / sidecar) init container using spec.initContainers[*].securityContext.seccompProfile

• for an ephermal container using spec.ephemeralContainers[*].securityContext.seccompProfile

• There is so much we can play around with!!

• Thanks to ChatGPT for the image, I wonder how my life would have been without you!