search

mozilla / sccache

Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.
Apache License 2.0
5.87k stars 552 forks source link

Document multi-tenant security considerations #845

Open DemiMarie opened 4 years ago

DemiMarie commented 4 years ago

What are the security considerations for running sccache distributed compilation in a multi-tenant environment? For this purpose, I assume that all of the clients trust the server, but not each other. The server does not trust any of the clients. Therefore, the server must ensure that the clients cannot poison the server’s build cache or escape the build sandbox.

drahnr commented 4 years ago

The last time I visited this topic, sccache assumes all participants to be trusted entities. A concept of trust levels is currently not implemented.

The most common setup I can imagine is a beefy CI machine / core developers which populates a generic, shared and trusted cache with myriad of external clients / semi-trusted participants which can feed from the shared cache and/or have an overlayed contained set of artefacts.

luser commented 4 years ago

Right, there's really no security model to speak of in sccache as a cache, clients trust the cache storage, and any client that has write access to the cache can store anything they like in there. It was designed first and foremost to serve as a replacement for ccache in CI environments with multiple ephemeral build machines, with a secondary goal to be a ccache replacement for local developers that offered some additional features like MSVC and rustc support.

The key issue from a security perspective is that the cache entries contain compiled object files which clients will link into binaries, and there's a high likelihood that the resulting binaries will get executed on the developers' machines. A sufficiently determined adversary with write access to the cache could store cache entries with malicious code in the object files that could attack developers' machines. Solving that problem is probably out of scope for sccache. There are other projects that exist that would be a better place to start, such as synchronicity.

I'm not familiar enough with how the shared cache model of tools like bazel works to compare, but obviously companies like Google do have internal shared artifact caches, so it seems plausible that there's a configuration that is secure enough to deploy in practice. If such a thing does not require additional security features then it would be reasonable to document what the important security properties are.

DemiMarie commented 4 years ago

@luser The way that Buildbarn does this is by only giving the trusted build hosts write access to the caches. All builds are done on the build hosts, and the build host ensures that every potential input to the build is included in the cache key. Builds are done in a sandbox, which prevents them from compromising the build server. This does not prevent an attacker from uploading malicious source that is compiled into a malicious object file. However, it does ensure that honest developers who submit non-malicious sources will fetch non-malicious objects.

Buildbarn can do this because it requires that all builds are hermetic: if something is not declared as an input to the build, the build does not have access to it. This is enforced by running the builds in a sandbox. Hermetic builds are also prerequisite for supporting the Bazel remote execution API (#358).

sccache’s build server already sandboxes builds using bubblewrap, and I would be more than happy to work on tightening its sandbox. The remaining tasks are ensuring that untrusted users do not have access to the cache, and ensuring that all build inputs are included in the cache.