Cargo security wishlist
Some poorly considered ideas
In a discussion with another open-source contributor I started listing some changes I’d like to see in the Rust ecosystem to reduce the chance and scope of potential supply chain attacks. It occurred to me it might be useful to write these down.
I’ve not put much thought into each of these. They range from ‘probably easy’ to ‘requires a fundamental rethink of Rust’s security model’, so take them with a pinch of salt.
Disable proc macros and build scripts by default
Procedural macros and build scripts perform arbitrary code execution on the build host. This is bad for obvious reasons. Restrict everything to a WASM sandbox, allowing only crates marked explicitly by the consuming crate as trusted to break out of it (some crates, like those that bind to C dependencies, have no option but to do so).
foo = { version = "1.2.3", unsandboxed_build = true }
Community-driven vulnerability reporting
Advisory DB, I love you. But the sheer volume of new discoveries is becoming overwhelming, and as the maintainer of several commonly used crates I would like a way to inform my users about problems that don’t meet the threshold of needing a CVE assigned but are nonetheless important. I shouldn’t have to go via a semi-third-party service to alert my users to an issue.
I notice that crates.io has gained a new security tab of late that pulls from the Advisory DB: let us put messages on there as crate authors! I can already yank versions arbitrarily, but I can’t tell my users why I yanked a version yet.
Knobs to control dependency resolution
I’d love to be able to tweak the dependency resolver to enforce dependency policies.
The most obvious one is publish date range: preventing selection of crate versions that are too old or too new seems like it would be a useful tool for security-conscious projects that want to minimise the chance of something nasty entering their lockfile before it’s been caught by the wider community.
Preventing inclusion of dependencies whose downloads or ‘trust rating’ (as measured by some hypothetically difficult to game value based on their degree of use in the wider ecosystem’s dependency graph) is below a threshold would also be nice.
Crate capability should be limited by default
Don’t allow a crate to use unsafe, perform IO, etc. unless I mark it as being
permitted to in my Cargo.toml.
The problem here is that rustc is not a security boundary, of course: while safe Rust is memory-safe by any reasonable definition, that promise falls away in the presence of an adverserial programmer. This is best thought of as a form of defence-in-depth.
A rugged language-level effect system would solve this problem better, but alas.