Sandboxing the process only works well when the malware requires more capabilities than the software itself.
So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a silver bullet.
Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.
The problem isn't the language here, it's cargo executing build.rs from dependencies which necessarily allows arbitrary code execution.
(as I and others have mentioned in the thread): The attacker can just move the malicious code from build.rs to lib.rs (ie. build-time -> test/execution-time).
Then the problem is the language, as the grandparent observes.
Sure, but I don't expect build to execute arbitrary code. That's a big difference.
It's like if `git clone` ran random stuff from the cloned repo.
Running what you've built when you've added a malicious dependency also causes arbitrary code execution.