4 ms·

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 priv

• wearsaredhat 7y ago
  Container security products like Twistlock require privileged access. I’m sure there are other use cases.
• rtempaccount1 7y ago
  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.
• ianamartin 7y ago
  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.
• Xylakant 7y ago
  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.
  • merb 7y ago
    well you can run that on the host directly and disable the init container.
    • Xylakant 7y ago
      Absolutely (though that requires host access), it just doesn’t seem to be what people do.
• tln 7y ago
  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.
  • mclehman 7y ago
    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
    • cyphar 7y ago
      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).
  • zapita 7y ago
    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.
• deathanatos 7y ago
  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.
• the8472 7y ago
  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.
• derefr 7y ago
  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.
• gcb0 7y ago
  > 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.
• shaklee3 7y ago
  Yes. You need privileged to run DPDK in a container.