Proposal: Security Working Group

134

OK, heard back from the core team. It’s on!

Mission and Scope

The WG’s mission is to make it easy to write secure code in Rust. We have the following concrete goals:

  1. Most tasks shouldn’t require dangerous features such as unsafe. This includes FFI.
  2. Mistakes in security code should be easily caught.
  3. It should be clear to programmers how to use security-sensitive APIs correctly.
  4. Security-critical code which is relied on by Rust programmers should be bug free.

Here are some examples of some work that we might do in service of these goals. All of these examples are possibilities, but we aren’t guaranteeing that we’ll tackle any given work item, and the list isn’t exhaustive.

  • Most tasks shouldn’t require dangerous features such as unsafe. This includes FFI.
    • Identify common uses of unsafe or other dangerous features, and write crates/stdlib features/language features to provide the same functionality behind safe APIs
  • Mistakes in security code should be easily caught.
    • Write clippy lints for common security mistakes
    • Make sure it’s easy to integrate new static analysis tools into Rust
  • It should be clear to programmers how to use security-sensitive APIs correctly.
    • Contribute to documentation of security-sensitive APIs in crates/stdlib
    • Write guidelines on how to design security-sensitive APIs
  • Security-critical code which is relied on by Rust programmers should be bug free.
    • Encourage/participate in bug hunting in stdlib/crates
    • Take ownership of the RustSec project

Out of Scope

Cryptography will be explicitly outside of the scope of the WG. There is interest from some in starting a Cryptography Working Group, but that will be left for other efforts.

The following responsibilities were proposed at various times in the preceding discussion, but we decided not to take those on as responsibilities for the WG:

  • Curating “approved” crates
    • Reasoning: It’s too early to get behind single solutions for many security problems, and important to leave room for more innovation and exploration. This may make sense in the future if there’s community consensus, but it doesn’t make sense now.
  • Support for memory corruption mitigations (stack canaries, CFI, etc)
    • Reasoning: Our efforts are better spent on improving memory safety and its adoption, which makes these mitigations unnecessary.
  • Fuzzing
    • Reasoning: There’s already a well-established fuzzing effort.
  • Rust security book
    • Reasoning: It’s unclear what would go in here, and in any case, not high enough priority to focus on right now.

Administrative

The WG will report to the core team.

Naming

We want to make sure that people don’t mistakenly think that we’re in charge of things like triaging security issues (that’s the core team’s job). Some have expressed concern that the name “Security Working Group” might lead people to believe that we’re in charge of all security for the Rust project. As such, we’re going to try coming up with a different name, but we need suggestions! The name should be short and pithy, and should be consistent with our mission to make writing secure code easy. Some alternatives that have been proposed:

  • Secure Code WG
  • Ecosystem Security WG

If you have ideas, join the discussion on Twitter.

5 Likes