Hacker News Reader

Comment by zeroxfe | Hacker News Reader

This is a weird kinda escape. The only time I use --privileged is when I'm debugging, _because_ it lets me easily elevate access. Does anyone actually run privileged containers for production workloads?

View on HN

If a thing can be done, some nontrivial number of people do it in production.

The number of people who do it in production is correlated with the complexity of the thing they are trying to do and how much the "fuck it, just do <some terrible idea>" relieves that complexity.

Docker containers that create/manipulate your Docker containers (e.g. the Kubernetes control plane) are --privileged, if they don't just mount the Docker daemon socket into themselves (which is basically equivalent.) If you're using kubectl, you're speaking to a daemon running in a --privileged Docker container, which you could perhaps exploit.

There's some cases where it's use in Kubernetes. Some of the system pods will run privileged and also some CNI pods will too.

Elasticsearch requires some sysctls set on the node and some of the helm charts around use a privileged init container to set those. A solution that’s obviously more or less accepted, though one I personally dislike.

well you can run that on the host directly and disable the init container.

Absolutely (though that requires host access), it just doesn’t seem to be what people do.

Not sure about production workloads but its not just privileged containers you start that should be a concern.. anyone who can access /var/run/docker.sock can run a privileged container, so this can be a privilege escalation.

Because of this escape, giving access to /var/run/docker.sock to regular users is the same as giving them root access.

Also as the article says mounting /var/run/docker.sock is (now, because of this escape) the same as giving that container access to the host system.

On the other side of things, my favorite demo for people new to docker who aren't yet aware that sudoless docker ~~ root access is:

    docker run -itv /:/host ubuntu chroot /host

Or, even better use nsenter to join all the namespaces of PID 1 on the host (making your process an ordinary root process in the init namespaces).

Mounting /var/run/docker.sock has always been the same as full host access. That is a well-documented fact irrespective of this particular escape.

Yes. We use Logspout, a container that attaches to the stderr/out of other containers and forwards those stderr/outs to more centralized logging services, such as an ELK stack. The attach call requires the docker socket, and so it is effectively a --privileged container.

The idea, of course, is to minimize the surface area for attacks. That container has a need for it to run that way; the vast majority of our other containers do not.

Container security products like Twistlock require privileged access. I’m sure there are other use cases.

Sometimes you need to disable at least some of the security features, e.g. to run gdb, perf. Or headless chrome with its security sandbox which just blows up with the default seccomp filters.

Yes. You need privileged to run DPDK in a container.

> when I'm debugging

Ironically, attackers would have access to more valuable data (and more freedom of movement) on your personal/dev box than on a monitored production host.

Reply on news.ycombinator.com