upvote
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.

reply
The problem isn't the language here, it's cargo executing build.rs from dependencies which necessarily allows arbitrary code execution.
reply
I don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?
reply
> Is it common for closed source software to give the source code to customers to build?

Yes, somewhat common. I work in embedded, and where a supplier gives us the ability to build their code it is a lot easier for us to deal with the next time we need a new build from them.

reply
Closed source software could apply too, if the execution model supports it (e.g. WebAssembly). Just because the format is binary and "unreadable", its permissions (accessible functions) don't have to be
reply