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.
The first stable release of a memory safe sudo implementation
31–40 of 260 posts
Re: The first stable release of a memory safe sudo implementation
#32[dead]
Re: The first stable release of a memory safe sudo implementation
#33Re: The first stable release of a memory safe sudo implementation
#34I 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 th…
> 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.
Re: The first stable release of a memory safe sudo implementation
#35I'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-ori...
One of those left out features is `sudoedit` or `sudo -e`. I use this a lot when editing files in /etc or any file that my user does not have permissions. The flag first copies the file to a temporary location with permissions for my user to edit, then opens my text editor (defined via $SUDO_EDITOR env var) as _my user_, without any sudo permissions. After I close the editor, the file is copied back with the original…
This would be a great use case for a capability security model. Essentially what you really want is the sudo command to acquire a temporary capability token to edit that specific file. Then run your editor and pass it the capability. (And revoke the capability when the editor process closes).
It’s a pity this isn’t more straight forward to implement on Linux.
Re: The first stable release of a memory safe sudo implementation
#36Earlier quoted context omitted.
One of those left out features is `sudoedit` or `sudo -e`. I use this a lot when editing files in /etc or any file that my user does not have permissions. The flag first copies the file to a temporary location with permissions for my user to edit, then opens my text editor (defined via $SUDO_EDITOR env var) as _my user_, without any sudo permissions. After I close the editor, the file is copied back with the original…
I usully use "sudo -E EDITOR_OF_MY_CHOICE"
Many editors can execute shell commands, so this isn't the same at all.
Re: The first stable release of a memory safe sudo implementation
#37> 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).
For better or worse the use of GPL is going away, even the future of Linux kernel is not guaranteed.
In the realm of IoT FOSS UNIX like operating systems, all the contendants are using a mix of Apache, MIT and BSD licenses, including the ZephyrOS sponsored by the Linux Foundation.
When the GPL generation is gone from the face of the Earth, it won't last long that UNIX-like OSes get another steward alternative to the Linux kernel, with a more appealing license to big corps.
Re: The first stable release of a memory safe sudo implementation
#38> 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).
Sudo is ISC-ish[0] (very permissive), not GPL. Su does indeed seem to be GPL though. [0]: https://www.sudo.ws/about/license/
The GNU ~~coreutils~~ util-linux version of su would be GPL but su is from Unix V1 (1971) so there are AT&T implementations, BSD implementiations, etc.
Re: The first stable release of a memory safe sudo implementation
#39> 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).
I wanted to write this comment too, as I have a serious concern that the effort to displace GPL tools with Rust rewrites in MIT/Apache will one day lead to a proprietary Linux, but the original sudo is not in GPL. It's in an ISC/MIT style license [1]. 1. https://www.sudo.ws/about/license/
Look at Android, the only GPL thing left is exactly the Linux kernel, and it hasn't been yet replaced by Zirkon because reasons.
Look at the FOSS UNIX like RTOS, none of them is GPL.
Re: The first stable release of a memory safe sudo implementation
#40Earlier quoted context omitted.
Moving away from the GPL is a very bad idea for such critical component. Exactly for the reason you give. (this post is just here to insist on the issue)
In general a lot of "[GNU tool] but in rust" projects do seem to come very close to violating the GPL, especially in spirit.
In what sense? It is completely in the spirit of the GPL to reimplement a GPL tool from scratch with the same behavior and a different license. After all, that's how the free Unixes came about (though admittedly those were BSD licensed typically).