Supply Chain Security of Base Image Sources

Various additional software is installed in the runner image from different sources. However, the authenticity of the downloaded software is not verified. Everything assumes that the transport encryption is sufficient. There sadly is no single solution for each software that is being added, because they originate from different sources.

🔥 Obviously supplying the images built as part of this project is also insecure, but I am going to create a dedicated issue for that later.

💡 Note that I am happy to help resolving these issues. I am only reporting it first so that there is a place to discuss. ☺️

git

https://github.com/actions-runner-controller/actions-runner-controller/blob/0b9bef2c086a54b0731fa7aa0a6bd7cb856b48ee/runner/Dockerfile#L14

This imports the GPG key of the PPA maintainer into the global apt-secure trust store and consequently ultimately trusts if for any package from any repository.^apt-key It is also using the HTTP URL of Launchpad, because the software-properties-common version that is part of the Ubuntu base we are using does not have the HTTPS patch.

The proper way would be to download the GPG key from a keyserver via the long fingerprint. Adding it to /usr/share/keyrings and adding a source that locks both the architecture and the singing key.

dumb-init

https://github.com/actions-runner-controller/actions-runner-controller/blob/0b9bef2c086a54b0731fa7aa0a6bd7cb856b48ee/runner/Dockerfile#L51

There is nothing with which we could verify the authenticity of the downloaded executable. The vendor provides some SHA hashes, but they are provided via the same channel. Hence, if someone gained access to change the release assets that someone can change those hashes as well. Quick fix would be to include the expected hash just like the version. Proper fix would be to either ask the vendor to provide a secure supply chain, or to switch to https://github.com/krallin/tini who provide proper signatures along their binaries.

docker

https://github.com/actions-runner-controller/actions-runner-controller/blob/0b9bef2c086a54b0731fa7aa0a6bd7cb856b48ee/runner/Dockerfile#L59

There is a proper Debian repository from where the binaries can be retrieved. I would say that this is the most secure way to get this into the image (same approach as with git, download key from keyserver, etc.).

actions-runner

https://github.com/actions-runner-controller/actions-runner-controller/blob/0b9bef2c086a54b0731fa7aa0a6bd7cb856b48ee/runner/Dockerfile#L100

This suffers from the same issue as dumb-init does. I would create an issue and ask for signing, until then the only fix is to hardcode the hashes along the desired version in our build and verify it.

Start with runner/Dockerfile at the referenced lines for git, dumb-init, docker, and actions-runner. Review how each source currently obtains keys, packages, or binaries and compare that with the verification concerns described in the issue. Done means the image build verifies the authenticity of each added component through an agreed approach.