no-dangerous-cap-add
disallow granting a Linux capability that lets a process act on the host, e.g. “SYS_ADMIN” or “SYS_MODULE”, via the “capAdd” property or a “–cap-add” entry in a devcontainer.json’s “runArgs”
Why
Container runtimes withhold the capabilities that let a process act on the host rather than on the container, and “capAdd” adds them back one at a time. Each capability this rule reports is on its own enough to reach past the container — loading a module into the host kernel, opening a file by handle outside the mounted filesystem, rebooting the machine — and none of them is granted by default, so one that appears here was asked for. Grant only what the workload actually fails without.
A capability the kernel confines to the container’s own namespaces is not reported, however privileged it sounds: “SYS_PTRACE” reaches no further than the container’s process namespace, and “NET_ADMIN” no further than its network namespace. What makes those dangerous is sharing the host’s namespaces, which is a separate rule.
Bad
{
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"capAdd": ["SYS_ADMIN"]
}
Good
{
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"capAdd": ["SYS_PTRACE"]
}