12 ms·

The first stable release of a memory safe sudo implementation

352 points by goranmoomin 3y ago

jackmott 3y ago
I remember a couple of years ago a root exploit in Sudo that was the result of failing to check for a sentinel value, thinking “that is a bug that wouldn’t happen in Rust, even though it isn’t related to memory safety!” Rust enums are sum types, and imho are one of the few unambiguously good language feature ideas. I miss them any time I use a language where they are not built in. F# is another nice language where they are first class and where I first got familiar with them
- Karellen 3y ago
  > Rust enums are sum types, I wouldn't mind so much if they just called them "sum types" or "tagged unions", or even some other new name. Reusing the existing name "enum" from other languages, but differently from the way all those other languages have used it for 45 gorram years, is freaking maddening.
  - n_plus_1_acc 3y ago
    That's inherited from OCaml I think. https://www.ocamlwiki.com/wiki/Enum https://www.ocamlwiki.com/wiki/Enum
    - ode 3y ago
      Nobody in the OCaml community commonly refers to them as Enum's today or any time recently (maybe they were at the time Rust was created though? IDK). They're usually called 'variants'.
    - debugnik 3y ago
      I don't think so, OCaml consistently calls them "variant types". I don't know who wrote that page, but that wiki didn't even exist before September and it isn't endorsed by ocaml.org, so I suggest you don't consider it authoritative.
  - cyber_kinetist 3y ago
    Swift and Scala also uses the enum keyword to define sum types, and their history goes earlier than Rust, so now you have multiple languages to yell at!
    - Karellen 3y ago
      Are you sure about Scala? I'm not familiar with it, but looking at the documentation it seems that an enum is a set of values, not a set of types? https://docs.scala-lang.org/scala3/reference/enums/enums.html https://docs.scala-lang.org/scala3/reference/enums/enums.htm...
garblegarble 3y ago
I'm assuming this project's aim is to replace sudo, in which case hand-waving away "Leaving out less commonly used features" is a bit worrying. What are these features? How uncommonly are they used? In which way will it fail if a configuration uses those features? Edit: Looks like their github readme outlines some of these limitations, https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...
- fermuch 3y ago
  It seems like those changes are noted here: https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...
  - garblegarble 3y ago
    The text seems to imply that's not a list of features not implemented, it's a list of features not implemented that don't output a clear error
- dtx1 3y ago
  Having so many different feeatures in one of the most basic unix tools is much more of a red flag.
  - garblegarble 3y ago
    For sure! But that mistake has already been made, and has been in the wild for years, so removing those features (and proposing yourself as a replacement for the original) is now a breaking change
    - mprovost 3y ago
      OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.
lynx23 3y ago
doas is 43184 bytes, and does everything I need. That sudo exploit was a wakeup call. If you haven't moved away from it yet, give opendoas (Debian package) a try.
- hannob 3y ago
  Do you use doas on Linux? It is not protected against tty pushback attack: https://github.com/Duncaen/OpenDoas/issues/106 https://github.com/Duncaen/OpenDoas/issues/106 That's a pretty severe unsolved security issue.
  - zokier 3y ago
    It's solved; TIOCSTI is disabled by default since Linux 6.2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
    - hannob 3y ago
      The thing you linked says "default y" to "Allow legacy TIOCSTI usage". So yeah, you can disable it, no, it's not the default. There's also a related issue with TIOCLINUX and the paste functionality. (That will however be solved in an upcoming kernel version. I wrote the patch for it :-)
      - csdvrx 3y ago
        > There's also a related issue with TIOCLINUX and the paste functionality. (That will however be solved in an upcoming kernel version. I wrote the patch for it :-) If anyone wants to apply that to their kernel, it's on https://lore.kernel.org/all/2023101158-esteemed-condiment-1dd6@gregkh/T/ https://lore.kernel.org/all/2023101158-esteemed-condiment-1d...
fdsfsdfdsffgg 3y ago
> Apache-2.0+MIT vs GPL-2.0 So, you may get a memory-safe su/sudo-rs, but those who distribute it in a binary form won't be obliged to show you the source code it was built from (potentially including some modifications).
- zigzag312 3y ago
  Is that really bad? You are free to not use such distributions. Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. GPL or no GPL.
  - EspressoGPT 3y ago
    > Is that really bad? You are free to not use such distributions. It's not really bad but it kinda defeats the purpose.
  - pbmonster 3y ago
    > Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. That's why hashes are published by distributors and checked by package managers, right?
    - zigzag312 3y ago
      That only checks that binaries are the same as what is published by distributors. It doesn't help against a malicious distributor, unless package managers also do a deterministic build themselves and verify that checksum from self-build binary matches the checksum published by a distributor.
      - pbmonster 3y ago
        If I'm not mistaken, many (most?) of the package managers of major Linux distributions actually build a package from source themselves in an automated process. Otherwise, getting a package to run on different architectures would be a ton of manual labor. At least Debian certainly has that automated. Besides the huge security risk involved in... just distributing random binaries?
_8j50 3y ago
IIRC, all the recent sudo vulns are logic errors, not memory safety. I mean, rewrite away but let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake.
- alpaca128 3y ago
  In the same way a new memory bug could be introduced to the original sudo. Shrinking the attack surface with static checks seems like a better deal in the long run.
- latexr 3y ago
  > let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake. Is anyone doing that? I see a lot of claims of memory safety, but as far as I can see the project isn’t saying other types of bugs are for sure eliminated.
  - _8j50 3y ago
    That's fair and i support that but it does not address historical bug patterns that may be a design issue.
- fanf2 3y ago
  2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156 https://nvd.nist.gov/vuln/detail/CVE-2021-3156 2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634 https://nvd.nist.gov/vuln/detail/CVE-2019-18634
  - _8j50 3y ago
    Fair point with the second one but for the first off by one is a logic error still?
    - Measter 3y ago
      It was a logic error... that led to a memory safety error, which resulted in a privilege escalation vulnerability. Just because the source is a logic error doesn't mean the end result can't be bad when combined with a lack of memory safety.
lindseyconcerns 3y ago
[dead]
slacka 3y ago
Would be interesting to see a a Debian derivative that combines this with the Rust Implementation Of GNU Coreutils.[1] Could be a big win for memory safety and performance. [1] https://github.com/uutils/coreutils https://github.com/uutils/coreutils
- guerrilla 3y ago
  I wonder how we are from a Rust UNIX userland. At least we wouldn't have to implement a C compiler!
  - yjftsjthsd-h 3y ago
    A Linux distro is going to need to see compiler to self-host regardless of the user land. If you can live without Linux, there's redox ( https://redox-os.org/ https://redox-os.org/ )
    - guerrilla 3y ago
      Well, I guess if the build system uses that distro or if it's a sourve distro.
  - nonameiguess 3y ago
    I looked into this a few years back when I was making my own toy Linux distro, and this is the list of packages provided by a typical GNU system that meet POSIX requirements for a userspace: * `bash` * `bc` * `binutils` * `bison` * `Coreutils` * `Diffutils` * `file` * `Findutils` * `flex` * `gawk` * `glibc` * `grep` * `tar` * `gzip` * `M4` * `make` * `man-db` * `man-pages` * `procps-ng` * `psmisc` * `sed` That's a reasonable start, but you also need, minimally, something to replace `pciutils`, `IPRoute2`, a bootloader, and an init system. For a close to expected experience, add in `TexInfo`, `XZ`, `ZStd`, and `bzip2`, plus `shadow` if you don't want passwords stored in plaintext. POSIX doesn't dictate an editor, but you probably want something that can run in a terminal. Usually `cURL` and either `openssl` or `GnuTLS`, plus `bind-utils`, `ldns`, or something equivalent are there for actually using the network, something to replicate `gpg` functionality if you're going to install signed packages, and of course the package manager itself. Cargo is fine for Rust app developers, but can't replace an installer of system packages. You likely need an `ssh` implementation to replace `OpenSSH`. I'm sure there's more I'm missing, but this is pretty close to what you'd get in a minimal server image. If you're looking to fully get rid of C and not need a C compiler, though, Linux itself is a hurdle. You don't necessarily need a kernel quite as fully-featured, but you need something that at least implements the POSIX system calls. Just about every Linux distro I'm aware of seems to also provide Python and Perl these days as a whole lot of system utilities and build scripts use them. Presumably, rewriting all of Perl and Python in Rust is not feasible, so you either need some other interpreted scripting language good for system scripting that is written in Rust, or somehow make your shell a superset of POSIX but also much closer to a real programming language. Don't underestimate the lift of replacing `libc`, either. It's not just the C standard library and interface to system calls. It also provides the linking loader that makes it possible to even run other programs, all of the locales and time zones, the system's name server, profiler, memory dumper. A whole lot of stuff.
coggs 3y ago
As one of the original creators of sudo (https://en.wikipedia.org/wiki/Sudo https://en.wikipedia.org/wiki/Sudo) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it possible for a single dev team to totally reimplement it without unknowingly introducing at least a bug or two? Is there something to this Rust language which magically eliminates all chances of any bug being introduced?
- narinxas 3y ago
  > Is there something to this Rust language which magically eliminates all chances of any bug being introduced? apperently, yes... and its the type system, but granted it's only 'memory safety' bugs... the kind of error that C languages are really suceptible to.
- noahjk 3y ago
  On the surface, sudo seems fairly straightforward, so it’s interesting to hear how much work has gone into it! Do you have any interesting facts or anecdotes you’d care to share?
  - nolok 3y ago
    The key is in "on the surface". While the common usage of sudo is fairly straightforward, you me and most people use like 5% of it. The trick is in all the side shows.
    - yesimahuman 3y ago
      Makes you wonder then why it does so much, if those rarely used features increase the surface area of possible exploits? This is just a question I’ve had about *nix utilities in general, since sudo is hardly the only tool with obscure flags and features
feldrim 3y ago
I'd love to see a verification / validation parameter/flag/tool that allows the user to dry-run the current sudo configuration and print out the parts unsupported by sudo-rs. Portability helpers for projects like these enable a frictionless change.
cyber_kinetist 3y ago
I think the two bullet points they listed for their project (other than using Rust) are often overlooked: - Leaving out less commonly used features so as to reduce attack surface - Developing an extensive test suite which even managed to find bugs in the original sudo Which are the most important aspects when writing any safety-critical code, even moreso than rewriting in Rust!
- Terretta 3y ago
  Are those more important than, say: - Proven with Coq, a formal proof management system: https://coq.inria.fr/ https://coq.inria.fr/ See in the real world: https://aws.amazon.com/security/provable-security/ https://aws.amazon.com/security/provable-security/ And check out Computer-Aided Verification (CAV).
  - Too 3y ago
    A formal proof is only as good as its requirements. Leaving out features and reducing complexity is for sure going to be more secure.
lambdaone 3y ago
This is good work, and I'm not quite sure why people are complaining about it; there clearly won't be any replacement of the traditional C sudo by this unless it's driven by distros and the community making it happen. Multiple implementations make it much easier to do fuzzing and generate automatic test suites that may be used to improve all the versions of this critical utility.
- thiht 3y ago
  As they say in the article, their test suite was even able to uncover 2 bugs in the original sudo. That's definitely a win.
brundolf 3y ago
By now we've gotten several projects that re-implement a core unix util in a safe language, often also with better performance due to concurrency, better standard primitives, etc Have any of these ever been adopted by a distro as the default implementation? Is that something that might happen? I.e. I would never bother to upgrade my sudo command or my grep command, but getting better defaults would be better Obviously they would have to be perfect drop-in equivalents, which some of these projects don't try to be, but others of them do
- steveklabnik 3y ago
  In 2021, uutils was far enough along and compatible enough to boot debian. I haven't heard of anyone actually moving to them fully yet.
charcircuit 3y ago
Having sudo itself makes an OS less secure since malware can use it to easily get root. Sure a rust version may be more secure, but even better would be deleting it entirely.
- AnonC 3y ago
  How else would you do things as root or superuser without exposing everything? If your sudo configuration is ALL = ALL (or is a variant of this), then sudo opens everything up for use/abuse. But if you carefully construct the configuration to allow only certain commands, it’s much better than just giving out the root password to users.
  - charcircuit 3y ago
    >How else would you do things as root Nothing a user is supposed to do should require elevating to root to do. >it’s much better than just giving out the root password to users. This is even worse. Access control should be set up properly instead of having users assume the identity of other accounts.
    - gitaarik 3y ago
      And so how do you then configure a server? Like modifying the files in /etc/
      - charcircuit 3y ago
        There are several different options 1. Don't. Just include the correct configuration as part of the OS. 2. For a configuration file use a group for passing out write access to users on the system. 3. Have a daemon which handles updating configuration files based off some central source of truth which pushes changes to a fleet of servers. Programs could directly communicate with this daemon to get their configuration.
- thebitstick 3y ago
  On a server, absolutely. On a desktop, the user is usually the administrator anyways. UAC exists on Windows land and the Administrator account is disabled for a reason.
markhahn 3y ago
Polishing a turd? Seriously, better reimplementations are great. But weren't you shocked to read about all those weird sudo features? I mean, the normal stuff is very weird, subtle, and therefore fragile. Anyone who uses sudo "deeply" should probably think about whether there are other ways.
declan_roberts 3y ago
I don't know why anyone is enamored with a rewrite of something as critical as sudo in a memory safe language, as if memory-safety somehow magically makes all of the other types of bugs disappear. No thanks. Keep this far away from all of my systems.
datadeft 3y ago
Doas is a much simpler tool for the same thing. I am not sure why it is not used more.
dang 3y ago
Recent and related: Sudo-rs' first security audit - https://news.ycombinator.com/item?id=38131442 https://news.ycombinator.com/item?id=38131442 - Nov 2023 (58 comments)
kelnos 3y ago
> Leaving out less commonly used features so as to reduce attack surface In principle I think this is a great idea, but when it comes to encouraging adoption, I think this might be a mistake. I would love to use this, but I'm not going to install it myself and make sure it stays updated. Realistically, I'm only going to use it if Debian decides to replace their sudo-c package with sudo-rs. And I just don't see Debian (known for being fairly conservative with changes and updates) doing that when sudo-rs doesn't implement sudo-c's full feature set.
oh_sigh 3y ago
Why do we need a memory safe re-implementation? Is there no way to wrap a binary and have it blow up if any attempts at memory unsafe accesses are detected?

352 points by goranmoomin 3y ago

I remember a couple of years ago a root exploit in Sudo that was the result of failing to check for a sentinel value, thinking “that is a bug that wouldn’t happen in Rust, even though it isn’t related to memory safety!” Rust enums are sum types, and imho are one of the few unambiguously good language feature ideas. I miss them any time I use a language where they are not built in. F# is another nice language where they are first class and where I first got familiar with them

Karellen 3y ago
> Rust enums are sum types, I wouldn't mind so much if they just called them "sum types" or "tagged unions", or even some other new name. Reusing the existing name "enum" from other languages, but differently from the way all those other languages have used it for 45 gorram years, is freaking maddening.
- n_plus_1_acc 3y ago
  That's inherited from OCaml I think. https://www.ocamlwiki.com/wiki/Enum https://www.ocamlwiki.com/wiki/Enum
  - ode 3y ago
    Nobody in the OCaml community commonly refers to them as Enum's today or any time recently (maybe they were at the time Rust was created though? IDK). They're usually called 'variants'.
  - debugnik 3y ago
    I don't think so, OCaml consistently calls them "variant types". I don't know who wrote that page, but that wiki didn't even exist before September and it isn't endorsed by ocaml.org, so I suggest you don't consider it authoritative.
- cyber_kinetist 3y ago
  Swift and Scala also uses the enum keyword to define sum types, and their history goes earlier than Rust, so now you have multiple languages to yell at!
  - Karellen 3y ago
    Are you sure about Scala? I'm not familiar with it, but looking at the documentation it seems that an enum is a set of values, not a set of types? https://docs.scala-lang.org/scala3/reference/enums/enums.html https://docs.scala-lang.org/scala3/reference/enums/enums.htm...

garblegarble 3y ago

I'm assuming this project's aim is to replace sudo, in which case hand-waving away "Leaving out less commonly used features" is a bit worrying. What are these features? How uncommonly are they used? In which way will it fail if a configuration uses those features? Edit: Looks like their github readme outlines some of these limitations, https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...

fermuch 3y ago
It seems like those changes are noted here: https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...
- garblegarble 3y ago
  The text seems to imply that's not a list of features not implemented, it's a list of features not implemented that don't output a clear error
dtx1 3y ago
Having so many different feeatures in one of the most basic unix tools is much more of a red flag.
- garblegarble 3y ago
  For sure! But that mistake has already been made, and has been in the wild for years, so removing those features (and proposing yourself as a replacement for the original) is now a breaking change
  - mprovost 3y ago
    OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.

lynx23 3y ago

doas is 43184 bytes, and does everything I need. That sudo exploit was a wakeup call. If you haven't moved away from it yet, give opendoas (Debian package) a try.

hannob 3y ago
Do you use doas on Linux? It is not protected against tty pushback attack: https://github.com/Duncaen/OpenDoas/issues/106 https://github.com/Duncaen/OpenDoas/issues/106 That's a pretty severe unsolved security issue.
- zokier 3y ago
  It's solved; TIOCSTI is disabled by default since Linux 6.2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - hannob 3y ago
    The thing you linked says "default y" to "Allow legacy TIOCSTI usage". So yeah, you can disable it, no, it's not the default. There's also a related issue with TIOCLINUX and the paste functionality. (That will however be solved in an upcoming kernel version. I wrote the patch for it :-)
    - csdvrx 3y ago
      > There's also a related issue with TIOCLINUX and the paste functionality. (That will however be solved in an upcoming kernel version. I wrote the patch for it :-) If anyone wants to apply that to their kernel, it's on https://lore.kernel.org/all/2023101158-esteemed-condiment-1dd6@gregkh/T/ https://lore.kernel.org/all/2023101158-esteemed-condiment-1d...

fdsfsdfdsffgg 3y ago

> Apache-2.0+MIT vs GPL-2.0 So, you may get a memory-safe su/sudo-rs, but those who distribute it in a binary form won't be obliged to show you the source code it was built from (potentially including some modifications).

zigzag312 3y ago
Is that really bad? You are free to not use such distributions. Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. GPL or no GPL.
- EspressoGPT 3y ago
  > Is that really bad? You are free to not use such distributions. It's not really bad but it kinda defeats the purpose.
- pbmonster 3y ago
  > Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. That's why hashes are published by distributors and checked by package managers, right?
  - zigzag312 3y ago
    That only checks that binaries are the same as what is published by distributors. It doesn't help against a malicious distributor, unless package managers also do a deterministic build themselves and verify that checksum from self-build binary matches the checksum published by a distributor.
    - pbmonster 3y ago
      If I'm not mistaken, many (most?) of the package managers of major Linux distributions actually build a package from source themselves in an automated process. Otherwise, getting a package to run on different architectures would be a ton of manual labor. At least Debian certainly has that automated. Besides the huge security risk involved in... just distributing random binaries?

_8j50 3y ago

IIRC, all the recent sudo vulns are logic errors, not memory safety. I mean, rewrite away but let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake.

alpaca128 3y ago
In the same way a new memory bug could be introduced to the original sudo. Shrinking the attack surface with static checks seems like a better deal in the long run.
latexr 3y ago
> let's not pretend that there couldn't be some new bug introduced due to a misunderstanding of how something works or just a plain old mistake. Is anyone doing that? I see a lot of claims of memory safety, but as far as I can see the project isn’t saying other types of bugs are for sure eliminated.
- _8j50 3y ago
  That's fair and i support that but it does not address historical bug patterns that may be a design issue.
fanf2 3y ago
2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156 https://nvd.nist.gov/vuln/detail/CVE-2021-3156 2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634 https://nvd.nist.gov/vuln/detail/CVE-2019-18634
- _8j50 3y ago
  Fair point with the second one but for the first off by one is a logic error still?
  - Measter 3y ago
    It was a logic error... that led to a memory safety error, which resulted in a privilege escalation vulnerability. Just because the source is a logic error doesn't mean the end result can't be bad when combined with a lack of memory safety.

lindseyconcerns 3y ago

[dead]

slacka 3y ago

Would be interesting to see a a Debian derivative that combines this with the Rust Implementation Of GNU Coreutils.[1] Could be a big win for memory safety and performance. [1] https://github.com/uutils/coreutils https://github.com/uutils/coreutils

guerrilla 3y ago
I wonder how we are from a Rust UNIX userland. At least we wouldn't have to implement a C compiler!
- yjftsjthsd-h 3y ago
  A Linux distro is going to need to see compiler to self-host regardless of the user land. If you can live without Linux, there's redox ( https://redox-os.org/ https://redox-os.org/ )
  - guerrilla 3y ago
    Well, I guess if the build system uses that distro or if it's a sourve distro.
- nonameiguess 3y ago
  I looked into this a few years back when I was making my own toy Linux distro, and this is the list of packages provided by a typical GNU system that meet POSIX requirements for a userspace: * `bash` * `bc` * `binutils` * `bison` * `Coreutils` * `Diffutils` * `file` * `Findutils` * `flex` * `gawk` * `glibc` * `grep` * `tar` * `gzip` * `M4` * `make` * `man-db` * `man-pages` * `procps-ng` * `psmisc` * `sed` That's a reasonable start, but you also need, minimally, something to replace `pciutils`, `IPRoute2`, a bootloader, and an init system. For a close to expected experience, add in `TexInfo`, `XZ`, `ZStd`, and `bzip2`, plus `shadow` if you don't want passwords stored in plaintext. POSIX doesn't dictate an editor, but you probably want something that can run in a terminal. Usually `cURL` and either `openssl` or `GnuTLS`, plus `bind-utils`, `ldns`, or something equivalent are there for actually using the network, something to replicate `gpg` functionality if you're going to install signed packages, and of course the package manager itself. Cargo is fine for Rust app developers, but can't replace an installer of system packages. You likely need an `ssh` implementation to replace `OpenSSH`. I'm sure there's more I'm missing, but this is pretty close to what you'd get in a minimal server image. If you're looking to fully get rid of C and not need a C compiler, though, Linux itself is a hurdle. You don't necessarily need a kernel quite as fully-featured, but you need something that at least implements the POSIX system calls. Just about every Linux distro I'm aware of seems to also provide Python and Perl these days as a whole lot of system utilities and build scripts use them. Presumably, rewriting all of Perl and Python in Rust is not feasible, so you either need some other interpreted scripting language good for system scripting that is written in Rust, or somehow make your shell a superset of POSIX but also much closer to a real programming language. Don't underestimate the lift of replacing `libc`, either. It's not just the C standard library and interface to system calls. It also provides the linking loader that makes it possible to even run other programs, all of the locales and time zones, the system's name server, profiler, memory dumper. A whole lot of stuff.

coggs 3y ago

As one of the original creators of sudo (https://en.wikipedia.org/wiki/Sudo https://en.wikipedia.org/wiki/Sudo) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it possible for a single dev team to totally reimplement it without unknowingly introducing at least a bug or two? Is there something to this Rust language which magically eliminates all chances of any bug being introduced?

narinxas 3y ago
> Is there something to this Rust language which magically eliminates all chances of any bug being introduced? apperently, yes... and its the type system, but granted it's only 'memory safety' bugs... the kind of error that C languages are really suceptible to.
noahjk 3y ago
On the surface, sudo seems fairly straightforward, so it’s interesting to hear how much work has gone into it! Do you have any interesting facts or anecdotes you’d care to share?
- nolok 3y ago
  The key is in "on the surface". While the common usage of sudo is fairly straightforward, you me and most people use like 5% of it. The trick is in all the side shows.
  - yesimahuman 3y ago
    Makes you wonder then why it does so much, if those rarely used features increase the surface area of possible exploits? This is just a question I’ve had about *nix utilities in general, since sudo is hardly the only tool with obscure flags and features

feldrim 3y ago

I'd love to see a verification / validation parameter/flag/tool that allows the user to dry-run the current sudo configuration and print out the parts unsupported by sudo-rs. Portability helpers for projects like these enable a frictionless change.

cyber_kinetist 3y ago

I think the two bullet points they listed for their project (other than using Rust) are often overlooked: - Leaving out less commonly used features so as to reduce attack surface - Developing an extensive test suite which even managed to find bugs in the original sudo Which are the most important aspects when writing any safety-critical code, even moreso than rewriting in Rust!

Terretta 3y ago
Are those more important than, say: - Proven with Coq, a formal proof management system: https://coq.inria.fr/ https://coq.inria.fr/ See in the real world: https://aws.amazon.com/security/provable-security/ https://aws.amazon.com/security/provable-security/ And check out Computer-Aided Verification (CAV).
- Too 3y ago
  A formal proof is only as good as its requirements. Leaving out features and reducing complexity is for sure going to be more secure.

lambdaone 3y ago

This is good work, and I'm not quite sure why people are complaining about it; there clearly won't be any replacement of the traditional C sudo by this unless it's driven by distros and the community making it happen. Multiple implementations make it much easier to do fuzzing and generate automatic test suites that may be used to improve all the versions of this critical utility.

thiht 3y ago
As they say in the article, their test suite was even able to uncover 2 bugs in the original sudo. That's definitely a win.

brundolf 3y ago

By now we've gotten several projects that re-implement a core unix util in a safe language, often also with better performance due to concurrency, better standard primitives, etc Have any of these ever been adopted by a distro as the default implementation? Is that something that might happen? I.e. I would never bother to upgrade my sudo command or my grep command, but getting better defaults would be better Obviously they would have to be perfect drop-in equivalents, which some of these projects don't try to be, but others of them do

steveklabnik 3y ago
In 2021, uutils was far enough along and compatible enough to boot debian. I haven't heard of anyone actually moving to them fully yet.

charcircuit 3y ago

Having sudo itself makes an OS less secure since malware can use it to easily get root. Sure a rust version may be more secure, but even better would be deleting it entirely.

AnonC 3y ago
How else would you do things as root or superuser without exposing everything? If your sudo configuration is ALL = ALL (or is a variant of this), then sudo opens everything up for use/abuse. But if you carefully construct the configuration to allow only certain commands, it’s much better than just giving out the root password to users.
- charcircuit 3y ago
  >How else would you do things as root Nothing a user is supposed to do should require elevating to root to do. >it’s much better than just giving out the root password to users. This is even worse. Access control should be set up properly instead of having users assume the identity of other accounts.
  - gitaarik 3y ago
    And so how do you then configure a server? Like modifying the files in /etc/
    - charcircuit 3y ago
      There are several different options 1. Don't. Just include the correct configuration as part of the OS. 2. For a configuration file use a group for passing out write access to users on the system. 3. Have a daemon which handles updating configuration files based off some central source of truth which pushes changes to a fleet of servers. Programs could directly communicate with this daemon to get their configuration.
thebitstick 3y ago
On a server, absolutely. On a desktop, the user is usually the administrator anyways. UAC exists on Windows land and the Administrator account is disabled for a reason.

markhahn 3y ago

Polishing a turd? Seriously, better reimplementations are great. But weren't you shocked to read about all those weird sudo features? I mean, the normal stuff is very weird, subtle, and therefore fragile. Anyone who uses sudo "deeply" should probably think about whether there are other ways.

declan_roberts 3y ago

I don't know why anyone is enamored with a rewrite of something as critical as sudo in a memory safe language, as if memory-safety somehow magically makes all of the other types of bugs disappear. No thanks. Keep this far away from all of my systems.

datadeft 3y ago

Doas is a much simpler tool for the same thing. I am not sure why it is not used more.

dang 3y ago

Recent and related: Sudo-rs' first security audit - https://news.ycombinator.com/item?id=38131442 https://news.ycombinator.com/item?id=38131442 - Nov 2023 (58 comments)

kelnos 3y ago

> Leaving out less commonly used features so as to reduce attack surface In principle I think this is a great idea, but when it comes to encouraging adoption, I think this might be a mistake. I would love to use this, but I'm not going to install it myself and make sure it stays updated. Realistically, I'm only going to use it if Debian decides to replace their sudo-c package with sudo-rs. And I just don't see Debian (known for being fairly conservative with changes and updates) doing that when sudo-rs doesn't implement sudo-c's full feature set.

oh_sigh 3y ago

Why do we need a memory safe re-implementation? Is there no way to wrap a binary and have it blow up if any attempts at memory unsafe accesses are detected?