why is running as root in the docker a problem? Isn't the whole point of containers to isolate the container? So what is the difference in a container running root or a user? If there is, wouldn't that be more of a docker bug?
I’m not saying “go run your all your Docker images as root”, but this is clearly FUD.
Non-privileged containers are still having "root", just with way fewer capabilities (See Docker [0] docs).
I’m not an expert, but I guess depending what you are doing the most problematic capability might be AUDIT_WRITE, because it is not namespaced and could be abused for DOSing syslog. But you might require it for things like sshd, sudo, adduser, passwd, …
Depending on how you are holding it the NET_BIND_SERVICE and NET_RAW can be an issue (depends on how your docker network looks like), but the others appear not to be a security issue per-se.
This page [1] gives a good overview on default capabilities, though they are also confusing to the reader with "better disable this".
I've created an issue, not sure if I have resources to fix their page though. [2]
[0]: https://docs.docker.com/engine/reference/run/#runtime-privil...
[1]: https://www.redhat.com/en/blog/secure-your-containers-one-we...
[2]: https://github.com/mhausenblas/canihaznonprivilegedcontainer...
Real world example: CVE from February 2019 which allowed escalation to root on host. It's preventable by (among other things) "a low privileged user inside the container".
See https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-fr...
Thank you for this link, I've only seen the initial CVE announcement.
> This is not FUD [...]
The site is practicing FUD, it accomplishes communicating a message in an untruthful fashion by mixing two different things into one. (Just check out their stack overflow links, it is not clear if they are talking about root or `--privileged`)
People are confused wether `docker root == host system root` and this site doesn't help them to get a better understanding whether or not it is the case. (It isn't) Plus it misses what its main goal should be, running a Secure Docker environment.
You are talking about a previous exploit, not a permanent issue. Keeping your host system up to date and additional hardenings is always going to be necessary in exposed environments.
> Use Docker containers with SELinux enabled (--selinux-enabled). This prevents processes inside the container from overwriting the host docker-runc binary.
Authors recommendation is also using SELinux, this also helped with outer Docker/Kernel related vulnerabilities in the past. Why isn't the page even mentioning this?
---
I think it is important to give a proper outlook on how problematic things are and not to confuse people with super high expectations. You often end up running containers that you have only little control about.
1. Avoiding root in self-built containers is definitively the way to go, since it reduces (unnecessary) attack surface, but
1. It requires some glue code
2. Might slow down your builds (`Dockerfile` multistage `cp --from=0 /app /app` loses permissions, requires chown afterwards)
2. some capabilities to test things (sshd for testing ansible scripts for example)
3. can you use kaniko for building Docker images from within Docker without root?
1. Use SELinux
2. Use monitoring
3. Drop capabilities that aren't necessary (NET_BIND_SERVICE, NET_RAW, ...)
4. Use docker network separation
5. Frequent system updates
Just googled and this is rather more helpful:
- https://dev.to/petermbenjamin/docker-security-best-practices...
- https://blog.aquasec.com/docker-security-best-practices
- https://sysdig.com/blog/7-docker-security-vulnerabilities/
You can't assume all containers have same access and trust-level as a user because at some point you also have to process your requests and store your data - and that processing is most likely also be done in another container (even if your actual data-volume is mounted outside the container). For such containers same security measures as for a physicial machine applies.