![]() For applications like this, changing the user is probably not what you want, and should be handled in the application configuration itself. Nginx requires root access to bind to port 80, but the processes handling user requests or executing further scripts (PHP etc) is configured inside nginx itself. Some applications, like nginx, already handle changing user as part of normal operation. This strategy works very well as it’ll make sure the application file permissions match the process user, so applications will always have access to their files. LinuxServer.io, the makers of a bunch of high-quality containers, use the $PUID and $PGID environment variables to configure the user and group of the process and related files. Note that this doesn’t change anything else about the container. This argument takes the user id of the user to change the process to. ![]() # Container usersĪs a container user, you’re at the mercy of the container maintainers as to the quality of the support for changing user.ĭocker itself supports changing the user using the -user argument (or user key in docker-compose.yml). Many containers, if configured incorrectly, will stop functioning entirely if you try to change the user without them expecting it. ![]() Not all containers will just deal with it. # Changing the userĬhanging the user running prevents the previous issues. If there’s a vulnerability in docker, or the kernel itself, allowing a process inside the container to break out, then they now have a process running on your host as root. With this, an attacker can not only mess with the application, but potentially install additional tools to help pivot to other devices or containers. Inside the container, the user is root, and so can do whatever they want in the container. If there’s a vulnerability in the application, then an attacker can gain root access into the container. Just because the process is in a container, doesn’t mean it’s completely protected, nor that these reasons don’t apply. There are so many reasons not to run all your processes as root. # “What’s wrong with containers running as root?” There may be ways of running without root, but it’s fine as it is. root is needed to configure certain container aspects needed to function correctly. dockerd (the docker daemon) runs as root, and this is normal. # “Who does a container run as?”īy default, containers are run as root. But, when inside a container, which user does the process run as. Whether that be a web server like Nginx, database like PostgreSQL or an init system like s6 to spawn and handle even more processes. Most commercial container hosting offerings just run your containers in VMs, to massively reduce inter-client security issues.Ī container is just a single process. VMs are a much better understood technology, and have a lot more isolation. Unlike VMs, containers run closer to the host operating system, so close they use the same kernel, meaning it’s even more important to protect it. “What’s wrong with containers running as root?”ĭocker containers, and containers as a whole, are really just a regular program wrapped in some extra protections provided by the kernel (namely cgroups etc) to create isolation, and other interesting features.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |