What makes Rust a high security language? What could be done better?


#1

I think we should be selling Rust as a high security, high performance language.

Regarding security, this is what I see:
Memory Safety
Thread Safety
Unit tests
Type system
No Exceptions, which allows warnings for unused Err Results meaning all errors can be provably caught and handled
No Garbage collector

What I think could be done better:

  • Better unit testing. I know it’s possible to plug into coveralls.io, but would be really nice if that could be done through cargo. Some way to generate a report indicating which lines had and had not been tested and how many times every line had been tested by unit tests. Or make it easier to automatically plug into coveralls.io
  • Dependent types and taint analysis could be nice. Taint analysis could probably be done compile time.

Related interesting link:
https://security.stackexchange.com/questions/55723/are-there-secure-languages

Plus security is extremely important to my own project, it’s why I picked Rust!

What security features am I missing? What do you see that could improve Rust’s security?


#2

Yes, coverage calculation for tests would be great thing.


#3

If you are going for high security, then the lack of full dependent-type-based provable code certainly has to be included. :slight_smile:


#4

I came across dependant types while researching this question. I don’t fully understand though, why are dependent types good for security?


#5

http://adam.chlipala.net/papers/CpdtJFR/CpdtJFR.pdf

Coq is based on dependent type theory. In particular, Coq’s implemented logic follows closely the formalism called the Calculus of Inductive Constructions.
By programming with dependent types, it is often possible to “prove theorems” without writing anything that looks like a proof. Instead, this work is done via an extension of the familiar ideas of type-checking, with some of the same light-weight feel when compared to classical formal methods. Dependent types are especially useful for encoding “boring” structural invariants of data in a way that prevents the construction of any invalid object.

There are a number of prominent proof-oriented languages using dependent types, including Coq, Idris, Agda, Lean, etc.


#6

That makes sense… I can see how there are definitely cases where you’d want to restrict data to only be valid under certain conditions, particularly for security reasons.

You might find this interesting:


#7

Hi,
I’m curious what’s the fundamental issue with a garbage collector with regard to security?


#8

What could be done better? Ranged integral values, like in Ada.


#9

The main problem is that a garbage collector normally isn’t deterministic. This means that you e.g. can know when a certain resource is freed or a destructor is called, which is a no-go in high security. Another issue is that it might just block the main program, but this is more of a problem for a high performance.


#10

As konstin said, it’s more of a performance issue for it to not be included into Rust.

However, I came across someone else saying it and have heard it in the past. I believe it has to do with “timing attacks”. Basically attackers can tell a little bit more about what the program is doing based on when it garbage collects. Additionally, there is some attack where if you have access you can reserve things in memory, then know when the garbage collector runs and again, it’s a timing attack due to knowing how often the garbage collector runs.

Plus it’s just one more complex thing running in another thread. It’s mostly great Rust doesn’t include it for performance reasons, but good for security too.