trifectatechfoundation / sudo-rs

A memory safe implementation of sudo and su.
Other
2.9k stars 79 forks source link

Ask questions #747

Closed rtczza closed 1 year ago

rtczza commented 1 year ago

I would like to ask a few questions:

We all know that Rust has better security than C and its performance is roughly on par with C’s.

How do we verify or prove that the safety of sudo-rs, refactored in Rust, is better than the original C code? Are there any tests or data that support this claim?

In terms of performance, what are the differences between refactored sudo-rs and the original C version? Have any tests been conducted?

When discussing the superior performance of Rust with others, it is important to provide specific test data rather than just emphasizing its inherent language-level safety. I am genuinely interested in discussing this topic and would appreciate any information or insights from experts who have knowledge about the above two questions. thank you.

rnijveld commented 1 year ago

The choice for using Rust for implementing sudo is generally not focused on performance. Authentication and authorization generally aren't performance sensitive and are mostly limited by the typing speed of the user authenticating. Other than that, sudo might have to do some transfers of data between two TTYs if a PTY is used, but in general for most use cases we don't transfer enormous amounts of data over that, which also limits the importance of performance. Of course it is important that sudo doesn't take up huge amounts of resources on your computer, while we have no detailed benchmarks at this time, we have not had any issues running it ourselves, but if you find any issues we'd love to know. And of course, we'd welcome anyone to run benchmarks on our code, but I'm not sure if we should focus our attention on that right now.

As for safety, this is all an effort in building confidence, given that completely proving such things is nearly impossible. Of course we are helped very much by Rust being memory safe. Most of our own efforts focus on our test suite (i.e. the test-framework directory in the source), by which we in fact found a few bugs in the original sudo implementation. You can read more about it in a blog post on the Ferrous website. Aside from that we of course try to limit our usage of unsafe as much as possible, and we also try to limit the supported features and limit our usage of external dependencies to decrease our attack surface. We do have a proof for our making sure that our algorithm always finds the correct rule in the sudoers file. We've also attempted to check every CVE and security advisory already issued for sudo previously in an attempt to make sure that we do not accidentally repeat the same mistakes. We've also been able to contact Todd Miller (the author of the original sudo) a few times to discuss some of the choices that were made in his implementation, which helped us tremendously as well. Other than that, most importantly, people will have to start using our implementation and report any bugs they find.