The security barrier must be earlier. It will make everything easier to secure. By analogy, it’s like securing your own house. You can lock points of entry to your house, and it’ll work fine for the entire house. But if you move the security barrier to wrong place because you assume burglars may freely roam inside your house, you’ll end up with locks on your bathroom, padlocks on your drawers, gates on your bed, TV stored in a safe, and kitchen utensils chained to walls.
Here, your OS is your house. If you work with assumption that you let malware in, and running viruses is normal part of Rust development, you’ll need extraordinary level of sandboxing paranoia similar to having things in your house chained to walls. It’s going to be incredibly hard to secure everything, and it’s going to be incredibly inconvenient to use the language that has to act at all times as if all your code was infected and dangerous.
A better approach is to make sure that there’s no path from the guest bedroom to the master bath. That means an OS should not be a monolithic whole, where penetrating any component gives full access to everything. For example, there is no reason why a network interface needs access to the file system, but that’s exactly what an exploit from a couple of years ago used. What we need is isolation among the components of the OS. CapRos and seL4 are examples of how it can be done by applying the Principle of Least Privilege at a finer level of granularity than the whole OS.
[Rust’s] unique selling point is that it unlocks a level of performance and flexibility that was previously not possible without investing in deep platform-specific knowledge and expensive quality assurance processes.