Regarding forbidding unsafe, I think it's commonly overestimated how much it would help, and underestimated how difficult it is to implement and how damaging it would be to the ecosystem.
Rust would have to create a new, much bigger concept of "unsafe", because:
-
std::process::Commandis safe -
#[no_mangle]is safe -
#[link_section]is safe -
#[export_name]is safe -
#[link(…)] extern "C" {}is safe -
println!("cargo:rustc-link-lib=native=…")is safe - proc-macros are safe, and turing-complete, and can inject all of the above in a way that evades static analyzers.
You can forbid all of that, but you lose a ton of Rust features, and the systems part of the systems programming language. And that is still not enough, because:
-
It creates a new, difficult threat model for every other crate. Now crates on allowlists that are permitted to use "big-unsafe" features have to treat their public API as a security boundary, and protect not just from memory safety invariants, but against all code that could abuse the API to gain access to the file system, network, or other data in the program through a blessed crate.
- There are also possible subtly-evil implementations of iterators, operator overloading and
Derefthat are themselves safe, but can be used to confuse and exploit other less-than-perfect code.
- There are also possible subtly-evil implementations of iterators, operator overloading and
-
Rust is not a sandbox language. The language, the compiler, linker, libc, LLVM, the whole toolchain has not been designed to deal with untrusted code coming from the inside, and is not equipped to deal with it in a robust way. If you declare there's a security boundary inside Rust crates, this boundary will be broken and exploited over and over again. It will be a false sense of security, and it will be a faucet dripping with Rust CVEs.
-
Crates don't need elevated privileges to do malicious things. A hashing library can be a backdoor for passwords. A regex or other string/path manipulation library can trick your program into generating dangerous paths/urls/markup. Parsers/serializers can inject arbitrary data into your files.