I think adding per-crate permissions to do undoable/unsafe things will lead us to permissions hell of devops in big deployments. Like Amazon S3 with gazillion options. I think it's time to do something radically different with 3rd party deps.
Even if we put aside safety issues, each crate brings ~10 more dependencies by default (i.e. without any features turned on), which bloats compile times. Maybe it's better to be able to shard 3rd party crates, and not update them automatically at all?
That’s a solution people already use (vendering and / lock files) but it doesn’t solve this particular problem.
The closest to a solution we have is dependency scanning against known CVEs.
Having per-crate permissions is, I think, the only way languages can evolve past this hell hole we call supply chain attacks. It’s not a silver bullet, there will be edge cases that can be bypassed and new problems it creates. But if it reduces the scope of where supply chains can attack and what they can do, then that’s still a massive win.
I also think you probably only need to restrict your dependencies. If you have a dep tree like this:
a
|-b
|-c
Then if crate a decides b isn't trusted, c would inherit the same trust rules. This would allow crates to be refactored, but keep the list of rules needed in big projects to a minimum. You just have to add explicit rules for sub-crates which need more permissions. Thats probably not a big deal in most cases.
(You might still, sometimes, want to be able to configure your project to allow privileged operations in c but not b. But thats an edge case. We'd just need to think through & add various options to Cargo.toml.)
I may have read not carefully, but what happens if you allow crate X to write files, and it gets compromised? Should we set restrictions on per-call base instead?
I see we may catch those situations when a crate starts reading/writing when it hadn't, or in an unexpected place, if we set restrictions per call, but this only limits the attack surface, not eliminates it.
...It may actually make 3rd party libraries such a big bureaucratic pain, that users will minimize their usage.
> I may have read not carefully, but what happens if you allow crate X to write files, and it gets compromised? Should we set restrictions on per-call base instead?
Yeah, these are important details to figure out. But lets not let perfect be the enemy of good here. We're arguing about what brand of lock to buy for the back door of the house, when the front door is currently wide open.
After all - I think most programs will allow 1 or, usually 0 crates to write files anyway. Limiting the attack surface to 1% of where it is today is a huge win, even if its not perfect.
When it comes to files, the privileged operation should really be opening a file (at some path). Writing to a file handle you've been given is relatively a much safer operation. Files should usually be (only) opened by the main process. Then the opened file handle can be handed to any functions / structs in 3rd party crates which need access.
Even if we put aside safety issues, each crate brings ~10 more dependencies by default (i.e. without any features turned on), which bloats compile times. Maybe it's better to be able to shard 3rd party crates, and not update them automatically at all?