And even if you could fix all of rustc's soundness holes, or otherwise prevent user code from exploiting them, a soundness bug in any third-party library can also make it possible for malicious crates to trigger arbitrary behavior from safe code. This is why, in the presence of malicious code, it's not sufficient to annotate capabilities of unsafe library code. You need to prove that every line of unsafe code is 100% sound, or the capability system can be evaded. If you can't provide correctness proofs for all the unsafe code, then you can no longer rely at all on static checking of "high-level" or "purely safe" crates; you need to review them for malicious code as well, regardless of what your capability system says.
This is why we need to emphasize that while Rust's static analyses are very good at limiting accidental vulnerabilties in non-malicious code, they are not a sandbox system that can place meaningful limits on malicious code.