Is docker build secure

Image Builds
, ,
1

We want to have a GitLab pipeline that allows all teams (even none-trusted ones) to run a “build” job. There is a few issues with that regarding security that we need confirmation on. Intuitively, the answer should all be yes, but we are not sure whether docker is made to support these untrusted use-cases, so our team is very hesitant. Unfortunately, we could not find a definitive answer to these questions

Scenario

In this scenario, we control the command to build, but not what is build and not the Dockerfile itself. They push to a GitLab repository, and we clone it to a shallow copy of the repository on this commit. Hence, the sources are under control of the adversary, yet they correspond to the definitely correct branch / commit.

After this checkout, we simply force docker build . on the repository sources, and tag it with the commit hash. We then push it to our registry. Hence, the built images and tags are correct and an adversary can for example not push an image to the master tag or the commit hash at HEAD for the master branch.

Note that the Dockerfile itself is under control of the adversary. Also, the docker build is docker-in-docker, so requires a privileged container, as we plan to use Kubernetes executor in the best case.

Security implications of…

… docker build

The first question that we are asking ourselves is, are there security implications to running docker build on arbitrary Dockerfiles? Yes, an adversary can run arbitrary code on our system, but it should all be neatly sandboxed(?), and a simple timeout on the build should prevent building forever.

Does the context (which is set to the cloned repository) restrict filesystem activity correctly? Can the Dockerfile somehow control the system’s filesystem? Is there something with symbolic links etc that we should be aware of? Are there any other attack vectors, or would any vulnerability in this regard just be a CVE as it is behavior that is not intended?

… caching

Given that we want our pipelines to be somewhat fast, we want to use caching for our developer branches. Can the adversary somehow poison our cache even though we are just running docker build .? Do we have to disable caching completely or is this safe to use in a such untrusted environment?

Thank you for looking at this and helping us out:)

2

One way to abuse your system is to run a crypto miner in Dockerfile, so it will take maximum CPU and allowed runtime, you might need to pay for it.

3

As long as you cannot run indefinitely and do a timeout, this is fine. I do not consider this an attack.

4

I am not good enough to break out of a container during docker build and using vulnerabilities of the kernel or possibly Docker, but I would not run any code based on a file that I have no control over. just because I don’t know how that can compromise my system unless I really trust that source. A container is not as strong isolation as a virtual machine, but if you also have a secure virtual machine where you can control and monitor network traffic and don’t have access to your other machines in a LAN network, I guess the risk is smaller. After all, even your own Git repository could be hacked, so if you don’t rely on only the isolation of containers, that could be fine.

But even without isolation issues, I can imagine using the disk so intensively that slowes everything else on your system that needs reading or writing the disk as long as the build is running and the timeout is not expired.

You could also run some scanning on the Dockerfile before running docker build.

https://trivy.dev/v0.67/docs/coverage/iac/docker/

Regarding caching, I guess a Dockerfile could download files that can stay on your host machine even after another layer hides that file by virtually deleting it. If an atackr has any other way to get into the host namespaces just to execute a single shell script or binary, that could increase the risk.

Again, I can’t tell you an exact example but I have a good imagination and I know atackers have even better.

While running processes in containers probably gives you a better security than just running the same on the host, it was not designed for fully securing your environment without other tools against skilled attackers.

So I would say it is not impossible to harm your system if you are using a Dockerfile that you have no control over, but depending on how much you trust the source, you can accept it. Especially when you also have a VM made only for the build so at least stealing data will not be likely if there is nothing critical next to that VM, not a big deal if that system slows down once if you notice that and act on it. And as I mentioned, you could try scanning the Dockerfile first in the pipeline