[foldr]

Just on a slight tangent, what are the security benefits of having a process run as a non-root user within a Docker container? It's obvious what the benefits are when running outside a container. Inside a container, on the other hand, there should only really be one important process running. That process will need to have access to all the interesting parts of the file system anyway, and being root inside a container doesn't let you do crazy superuser stuff like installing a kernel module.

[coredog64]

If you don’t at least drop the sys_module cap, you can install a kernel module [0]. Running as root inside the container increases the risk of a breakout. I’ve seen different approaches at different companies. One bank required a hard-to-get security sign off that included MFA to start (so no automation). A different bank bought expensive monitoring tools and then threw a bunch of money at refining the outputs.

[0] https://blog.pentesteracademy.com/abusing-sys-module-capabil...

[Cthulhu_]

It does allow you to exit the boundaries of the application though, and e.g. extract the application's database.

That said, is it possible to disable superuser access entirely in a container? Can't login as root if there is no root.

[nix23]

https://developers.redhat.com/blog/2020/09/25/rootless-conta...

[mattacular]

Docker has a user namespacing feature which can be used to harden container images and also a newer way to run rootless altogether - https://docs.docker.com/engine/security/rootless/

[dec0dedab0de]

If the application user has access to the database, it doesn't matter if you get access to root or not.

[mattacular]

If you've got root on a container, depending on how it's configured, you can gain access to the host in some situations (eg. Using volumes)

[foldr]

But non-root users within the container can also access mounted volumes, no? Is there some kind of exploit that only works if running as root?

[lights0123]

You can setuid root in a volume mounted in host. If that's executed at all by any user, bam you have root on the host.

If it's never executed, I don't know what vulnerabilities they were talking about.

[foldr]

Right, but it seems that wouldn't require the app within the Docker container to be running as root to work?

[nix23]

What a shitty concept. Typical Linux NIH (learn from zones jails lpar...no we need to reinvent the wheel in square format)

[turminal]

Linux namespaces are quite flexible and aren't used just for docker style containerization. In some use cases having a shared user namespace makes sense.

Docker just doesn't use the provided interface by default. Which is a shame because a lot of users don't bother or don't know they should bother to configure it.

I think that's kind of a 'we don't care about security' move by docker and given its userbase that's a real problem.

[nix23]

Hmm, i come from a Solaris/BSD background, Jailing (or containerize) a application was all about security, second manageability, and third re-usability. Kind of crazy that Docker ignored the most important thing in the Container-Concept (which can be, run un-trusted code on your trusted platform.)

[tannhaeuser]

Docker really is a power tool for developers, especially for freelancers needing to hop customer environments on their own notebook, and excels at that. The problem is the leap of pushing this guerilla tactics into running containers in prod. It's a result of the "move fast and break shit", web-scale, startup, and other agile narrative of the 2010s. And the industry has sure catered for these consumerisation of IT, with outlandish complexity in k8s, depressing oligopolization, and younger developers demanding such technologies to pad their resumes.

[nix23]

One of the most outraging thing i seen in the past: Docker-host as a VM (for security) i mean WTF!!