Hey guys, thank you for the information and feedback. T0rqueWr3nch, I appreciate the analysis on the viability of Docker-rootless on Slackware, that could be an interesting option to look into.
I can give a little input on the situation, as the container security specialist on the Unraid team.
In general, containers are designed to be just as secure as virtual machines, with no chance of break-out when used properly, even when running as root. This is because the Docker runtime takes advantage of cgroups and namespace features built into the Linux kernel, allowing full process isolation on a shared kernel, at the cost of a larger attack surface.
In the rare event that a vulnerability is found in Docker or the Linux kernel that does allow a container to break-out, it's a big deal. This is why this vulnerability, that allows attackers to break out of the filesystem namespace, has been hitting the headlines under the name "Leaky Vessels".
https://snyk.io/blog/leaky-vessels-docker-runc-container-breakout-vulnerabilities/
Of course, when security is important, you don't want to just have one line of defense against attackers, as we've just seen with this vulnerability. That's where security features like uid namespaces, non-root container processes, non-root docker daemons, and isolated kernels come into play.
We already use these security hardening features for our cloud infrastructure here at Unraid, which is why our websites and Unraid Connect were not directly affected by this vulnerability.
However, these security features have tradeoffs when it comes to usability, which is why they are not used/enforced in the OS. The most obvious one is being able to access files on your array, but many third party containers are also just not compatible with security hardening and will not work with "--user 1000". There are also many kinds of workloads, such as DHCP servers or device passthrough, that aren't possible without root or privileged access to the Unraid server host.
I have dealt with these incompatibilities a lot as a Red Hat consultant for Red Hat Openshift Kubernetes, where containers are always blocked from running as root. It breaks a lot of container images, and it can be very frustrating!
It's worth noting that the impact of "Leaky Vessels" CVE-2024-21626 does not change whether your container runs as root or not. The vulnerability cannot be mitigated by using the the "--user" option to force processes to spawn as a non-root user. The vulnerability allows attackers to steal the root permissions of runc, which is always root in all but the most hardened container runtimes.
https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/
(Counter examples of runtimes that don't run as root would be Podman and the aforementioned docker-rootless, but these are not officially supported by any major Linux distro and have major incompatibilities with standard (rootful) Docker)
In any case, we're working hard to get this security update out to users and close this rare security gap. If you want to increase your security level beyond the Docker default going forward, I would make sure that you're running reputable docker images that take security seriously, and that use the "USER" directive in their dockerfiles to run as a non-root user in a consistent way.
In cases where secure docker images aren't available, you could try writing some of your own dockerfiles. It's a very good skill to have as a sysadmin with the growing Cloud Native IT landscape, and you can ensure that your container is secure and compatible with security hardening. Most of the containers that we use for Unraid's cloud infrastructure are written and maintained by our own team. Tools like Github Actions and Github Container Repository (GHCR) make it very easy to publish Docker images from a git repo for free.
Here are good tutorials for writing your own dockerfiles and publishing your own Docker images from Github using Github Actions and GHCR:
https://linuxize.com/post/how-to-build-docker-images-with-dockerfile/
https://docs.github.com/en/actions/publishing-packages/publishing-docker-images
Yeah, I was actually thinking to myself about how good Podman is when I wrote my reply. There's a few disadvantages when it comes to development tools like docker-compose and Tilt when running it on a workstation, and you often can't use containers that talk directly to the Docker socket, but it strikes a really good balance between security and usability for server workloads. That's a really good feature request, I'm not responsible for the Docker subsystem in Unraid, but I'll bring it up in our internal discussions.
