According to a recent shareholder letter from…
Containerd is an industry-standard runtime container that is available for Linux and Windows as a daemon. The containerd-shim API was wrongly exposed to host network containers in containers prior to versions 1.3.9 and 1.4.3.
08:46 GMT, Tuesday, December 1, 2020
The shim API socket access controls checked that the link mechanism had an efficient UID of 0, but did not otherwise limit access to the abstract Unix domain socket. With an effective UID of 0, but otherwise reduced privileges, this would allow malicious containers running in the same network namespace as the shim to enable new processes to be run with elevated privileges. In containers 1.3.9 and 1.4.3, this weakness was patched. As soon as they are released, users can migrate to these models.
It should be remembered that containers started with an old containerd-shim version should be stopped and restarted, as even after an update, running containers would continue to be vulnerable.
If you do not grant untrusted users the ability to start containers in the same network namespace as shim (typically host network namespace, such as docker run —net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, this problem is not sensitive.
If you run containers with a compromised setup, you can refuse access to all AppArmor abstract sockets by adding to your policy a line close to deny unix [email protected]**. Running containers with a limited collection of privileges, with a non-zero UID and with isolated namespaces is best practice.
The container keepers clearly warn against the host’s exchange of namespaces. Reducing the collection of isolation methods used by a container inevitably increases the privilege of the container, regardless of what runtime of the container is used to operate the container.