Proposal: Security Working Group

120

Okay, let me copypaste a strawman proposal I came up with a while ago:

Turns out “security” is a very broad term, and the discussion is running in a zillion different directions, i.e. going nowhere. So I came up a strawman proposal that’s actionable and can be communicated clearly.

Namely: form a “Safety WG”. Mission: make memory errors a thing of the past.

Goals:

  1. Identify when people use unsafe, eliminate the need to use unsafe in typical code by providing safe alternatives.
  2. Ensure that the safe alternatives are actually propagated through the ecosystem.
  3. Make sure the inherently unsafe code such as stdlib is trustworthy.

Communications channel for WG: a channel in https://rust-lang.zulipchat.com/ because it’s a chat with discussion structured by topics, that’s where part of the core Rust team hangs out so they will be close by, that’s what unsafe code guidelines WG uses so it would be close by.

Status meetings: weekly, while the WG is young. May transition to once in two weeks later if/when we feel like it. 20:00 UTC every Wednesday so we won’t overlap with Unsafe Guidelines WG.

Place to put links and write down info: github repository, similarly to unsafe-code-guidelines

Here are some work items that are actionable right now:

  1. Pick a popular crate that uses unsafe, check out why it does that, try turn it into safe code without regressing performance; document how you did it if you succeed, document why that failed if you didn’t. Write it down in WG github repo. Marketable as “safety blitz”.
  2. Fuzz crates that haven’t been fuzzed, report discovered issues to maintainers and RustSec advisory DB. Also note what pattern caused the vuln to happen in the WG repo.
  3. #1 and #2 will let us gauge what patterns work, what don’t, what safe APIs are needed but missing. This should be turned into guidelines and/or Clippy warnings.
  4. Try out those safe wrappers for common unsafes (zerocopy crate), open PRs for real projects replacing unsafe with them and possibly safemem as well, see how that goes and whether it degrades performance/ergonomics/whatever. Record results in WG repo and on relevant wrapper crate issue tracker.
  5. Join the effort of verifying the standard library using fuzzers and quickcheck at https://github.com/blt/bughunt-rust
  6. Get Memory Sanitizer to work with Rust’s standard library (it currently doesn’t).
  7. Set up a bot that parses crates.io public index and periodically audits it for crates that depend on other crates known to be vulnerable by inspecting their Cargo.toml and Cargo.lock, and either files an issue automatically or alerts a human.
  8. Write a beginner’s guide to using SMACK to verify correctness of Rust programs; it’s a symbolic execution engine that has been adapted for Rust recently.

I have a blog post in the works on how I’ve discovered RustSec-2018-0004 and the shortcomings of the Rust APIs and/or idioms that made it possible, which should lay the groundwork for #1 and add some more actionable items in that category. The TL;DR is that it’s surprisingly hard to write into a preallocated buffer safely, and we should be doing something about it. I’ve started a thread about that here.

3 Likes