1

I was always told logging in as the root user was bad practice. However, this is what Docker does by default inside its containers, and certain packages print warnings because of this.

Should I switch to a standard user and use sudo inside my container, or does this provide no benefits over using the root user inside a Docker container?

My container is running php8.1:apache (on Debian 11), and I use it on my website’s server. It has two ports open and a shared volume (the web application inside /var/www/hmtl/). Sudo does bring some additional complexities, in the form of a few more instructions in the Dockerfile and environment variables not accessible to some commands.

Mat
  • 833
  • 1
  • 5
  • 20

1 Answers1

1

I would actively avoid installing sudo in a Docker container. It is unnecessary, and the most common examples of setting it up are actively insecure.

In the context of a Dockerfile, you can use a USER directive as often as you need to switch users.

FROM some-base-image-with-a-non-root-user

USER root
RUN apt-get update && apt-get install ...
USER nonroot

A Docker container only runs a single process. If you need to run it as another user for whatever reason, including as root, you can use the docker run -u option.

docker run --rm -u root ubuntu cat /etc/shadow

# but more often, as the host user
docker run --rm -u $(id -u):$(id -g) -v "$PWD:/data" some-image

You should avoid doing work "inside containers", since anything you manually change will be lost as soon as the container exits. For example, I'd generally discourage docker exec ... apt-get install since it's asking to lose work. But if you do need to debug inside a container as root for whatever reason, docker exec -u is also an option.

@will-wright-eng links to How to use sudo inside a docker container? and there you can see the common security mistakes:

# don't do this, it's not necessary
RUN apt-get update && apt-get install -y sudo

# don't give a user a hard-coded password, that's trivially
# guessable, and recorded in the Dockerfile and history in plain text
RUN useradd docker && echo "docker:docker" | chpasswd

# don't allow the user to do anything anyways, so long as they
# ask nicely first
RUN echo "docker ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

Giving the user unrestricted sudo access makes them effectively root. Having to ask nicely gives you a little bit of protection. But, imagine your code has a remote-execution vulnerability, and an attacker has some sort of rootkit, but it involves actually being root; you can be sure they'll try to see if sudo rootkit escalate works without a password.

Some package managers complain about being run as root (Python's pip comes to mind here). It's okay to suppress these warnings. Since you're running in the isolated environment of a Docker image, you're not going to accidentally corrupt the "system" packages of a shared Python installation.

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • Thanks! So it seems like sudo in a container effectively only serves to suppress package complaints, at the price of giving a false sense of security. And having to be explicit about making any changes to the system, but that’s the whole point of a Dockerfile anyway. This makes me think that as long as remote access to the Docker daemon is disabled, if an attacker gets access to the server they get access to the container too, and whether the container was built and run using sudo or root isn’t going to change a thing. – Mat Oct 13 '22 at 21:12