Separating fetching from building for better security

Cargo and rust-analyzer are great, but their convenience comes with some security challenges:

• Like other language package managers, Cargo is subject to supply-chain attacks;
• Rust might be particularly exposed in that merely building a project can execute arbitrary code from any dependency via build scripts and proc macros. There are efforts to address this problem, but as far as I can see, a solution is not imminent;
• rust-analyzer, while extremely useful and convenient, is arguably particularly troublesome in terms of security.

I’ve been working on what I hope is a pragmatic remedy to these problems:

The Rust Programming Language Forum – 11 Jun 26

Sandboxed wrappers for Cargo and rust-analyzer on Linux

announcements

I continued developing and using these wrappers. With the latest release (0.3.0) they are now drop-in replacements for real Cargo and rust-analyzer for most practical workflows. The additional value that the wrappers provide is maintaining two...

While working on this, I realized that in addition to simply sandboxing Cargo, a meaningful security improvement can be obtained by separating fetching and building so that, for example, an invocation of cargo build is split into two phases:

• A first phase that roughly runs cargo fetch in a sandbox with network enabled.

• A second phase that runs cargo build --locked in a sandbox with network disabled.

The security gain from the above is that if a compromised dependency tried to exfiltrate user data over the network (even if a sandbox is used, sensitive project data might be available), it would have a much harder time doing so.

The hard problem is reproducing exactly the fetches that a particular Cargo/rust-analyzer invocation would perform, including features, targets, manifests, sysroot/library details, etc. The Cargo and rust-analyzer wrappers that I’ve been working on try their best, but with current Cargo this is necessarily a brittle affair. For example, truly replicating the fetches that some cargo build invocation would perform without running cargo build seems very difficult currently. The same problem exists for rust-analyzer’s fetches. My wrapper has to resort to running magic commands like

__CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS=nightly RUSTUP_TOOLCHAIN=$sysroot \
cargo fetch --locked --manifest-path "$library_manifest"

I wonder whether it would be a good idea to solve this brittleness by adding support for such sandboxing/separation to Cargo itself. Cargo could, for example, gain a --fetch-only option. Running cargo --fetch-only build would perform exactly the fetching that cargo build would otherwise perform, but stop before building. Rust-analyzer could gain a --fetch-only option as well.