Intro

First thing that comes to mind when you talk about containers is Docker. Docker has improved CI/CD agility and helped development teams deploy code to production faster. With this increased usage of docker, the security risks have increased too.

The distinction of what constitutes source code is blurred and developers now have additional responsibility to maintain Dockerfiles. A Dockerfile is a set of instructions that need to be passed to the docker daemon to prepare a docker container.

This is the first in a series of posts to cover some of the basics required to improve security of a Dockerfile. The first category that has the potential to end up as a critical vulnerability is:

Default Privileges

Docker defaults to root user if no user is specified.

In a typical scenario, you start the docker daemon on your machine, add a base image and install packages on top of the base image. The docker daemon requires root privileges but the containers (and applications) that run on top of the daemon do not typically require root privileges.

It is a common practice to run applications as a non-privileged user while deploying on a traditional server. Docker deployments also need to be treated with the same concern because user privileges are propagated inside the containers as well. You always want to run your containers as a non-root user to conform to the ‘Principle of least Privilege’ (https://csrc.nist.gov/glossary/term/Principle_of_Least_Privilege) to help limit access to resources in case of vulnerabilities.

Consider this scenario where the root user has some excellent tips on how to make money quickly and you want to know that. It is stored at this location - /opt/tips/how-to-make-money-quickly.txt where the user sidd doesn’t have permission to read.

sidd@ubuntu:~/opt/tips$ cat how-to-make-money-quickly.txt
cat: how-to-make-money-quickly.txt: Permission denied

sidd@ubuntu:/opt/tips$ ls -alt
-rw------- 1 root root   12 Apr 15 14:09 how-to-make-money-quickly.txt

Assume there is a Dockerfile in your system and the user sidd is a non-root user and is part of the docker group. Contents of the Dockerfile can be as little as having a single line with a base image or any Dockerfile that doesn’t have USER instruction. For simplicity, we’ll consider the following line is present in the Dockerfile
FROM ubuntu:latest

Build your image
docker build -t quick-money .

Run the image using
docker run -v /:/host -it quick-money

The above step logs user sidd into the docker container with root privileges and mounts the entire host filesystem to the container. You can go and read how to make money quickly!

The last step shows how you could add your user to the sudoers file so that you don’t have to type in your password every time. You can even go ahead and disable logging of sudo commands by adding Defaults:sidd !syslog to the sudoers file.

Now, the user sidd has full root privileges in the host machine and can perform all actions that the root user can perform.

How to mitigate this problem?

Base images like the one we used in the above example [Ubuntu:latest] has the current user set to root. This is done to allow users to install additional packages which require elevated privileges.

One way to remediate this issue is to run the docker with `-u` switch and provide a suitable UID>1000 since the first 999 is reserved for system accounts and services.

docker run --rm -u 5000 appUser 
where `-u` specifies the userID. Problem with doing docker run is that you have to remember to provide the `-u` switch every time you start your container.

A better alternative is to provide USER instruction as part of the Dockerfile. Even if the user is not actually present, we can provision a user by adding these lines to the above Dockerfile example

FROM ubuntu:latest
RUN useradd -ms /bin/bash appUser
USER appUser

Let’s try to read the same tips with the new Dockerfile

This method of adding USER instruction is better because it provides a consistent way to reduce privileges. It is a simple step to improve the security of your Dockerfile.

In this article, we saw how easy it is to get root access to the server if your docker container has root permissions, and how it is equally easy to fix using the USER instruction. Additionally, add only trusted users to the docker group. There are many more actions you can take to improve docker security. You can read about some of them here - https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

Enjoy and stay tuned!

More information:

Have technical questions about Micro Focus Security products? Visit the Security Community and click the product you want to learn more about.

We’d love to hear your thoughts on this blog. Log in or register to comment below.