Proposal: document Dockerfile building security promises

[nakedible]

Currently it seems very hard to find any documentation on what kind of security is promised by Dockerfile execution, especially if building Dockerfiles from untrusted sources.

As far as I can gather, the security is as follows:

• context directory contents are available, but there is no access to files outside it
• full access to network is available as if running an untrusted docker image
• escalating access to host is prevented with the same strength as normal untrusted docker images
• resource constraints are given in docker build command line

This means that if these limitations are acceptable, it is possible to allow building Dockerfiles from untrusted sources without creating a separate VM or similar to contain the build.

I assume something like this is already done by Docker Hub when builds are submitted to it, as it probably does not use a separate VM for each build, so the priviledge separation probably has been tested quite rigorously.

Is my assessment correct? Should this be explicitly documented somewhere?

[thaJeztah]

Is my assessment correct? Should this be explicitly documented somewhere?

I think that documenting it would indeed be a nice addition; I don't think we currently mention this

I assume something like this is already done by Docker Hub when builds are submitted to it, as it probably does not use a separate VM for each build, so the priviledge separation probably has been tested quite rigorously.

Actually, Docker Hub uses dedicated nodes for each account/build, but the main reason here was performance, and security from a different perspective; so that Docker Hub can guarantee no build artifacts are left on the machine that your automated build is executed on. See the blog announcement here; https://blog.docker.com/2015/11/upgraded-autobuild-docker-hub/

With our new infrastructure, each user has their own private build queue This way your builds will start quickly and in a predictable manner.

In addition, builds are now more secure. The build system spins up a new build node for each build request. This guarantees that private build artifacts that may be left over from one build cannot be retrieved by a malicious user.

ping @NathanMcCauley @diogomonica @tiborvass I think the above description is correct, but is there anything I overlooked?

[thaJeztah]

Thinking a bit more; one possible resource exhaustion is disk space; disk space is not limited, so docker build could use up available disk space on the host (either through the container's filesystem, or if a VOLUME is present in the Dockerfile)

[nakedible]

Right, disk space needs to be mentioned also as a limitation, although that's probably acceptable to most as well and could be controlled by quotas/whatever.

[collimarco]

I asked a similar question a few days ago: https://stackoverflow.com/questions/65647751/building-docker-images-provided-by-untrusted-users-in-a-saas

For now the only solution that I have found is to create/destroy a VM for every build... But that is not straightforward.

Are there any updates on this? Have you found any solution to safely build an untrusted Dockerfile inside a multi-tenant environment?

[thaJeztah]

For now the only solution that I have found is to create/destroy a VM for every build... But that is not straightforward.

Running a "per user" rootless daemon could help to some extend, but overall, this would still be my recommendation when dealing with fully untrusted loads.

Also things to add to the list;

• docker build --network=host .... should be considered "dangerous" when allowing untrusted builds (if users are allowed to specify that for their builds), e.g. see CVE-2020-15257 as an example
• local image cache: if a multi-tenant situation allows multiple users to (concurrently) share a machine and sharing the same dockerd daemon (no cleanup of state), those users would be able to access other's build-artefacts (user A builds myprivateimage:latest, then user B would theoretically be able to access myprivateimage:latest of user A)
• IIRC, process information from other processes running on the host could potentially leak through /proc (depends on kernel)

[cpuguy83]

It may be worthwhile, at least for docker build for us to supply a custom procfs as lxc does. And disable CAP_NET_RAW if it is not already.

[bain3]

Hi! Any updates? I'd like to know how building an image compares to running a container. Unfortunately I haven't found any documentation around build security so far...

[thaJeztah]

Let me transfer this to the buildkit repository, as that's where the builder is now maintained (we should indeed look at spending some time documenting more of this)

[jedevc]

Buildkit's security boundary is documented here: https://github.com/moby/buildkit/blob/master/PROJECT.md#security-boundary

There's obviously the potential to improve it, but we do have something already existing there.

[thaJeztah]

Ah, yes, we were going through some old tickets in moby/moby, and stumbled on this one. Let me /cc @dvdksn as well to see if there's things to improve (and / or move / copy to relevant sections in the docs)