Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The first stable release of a memory safe sudo implementation

memorysafety.org

Post reply on HN
Print view View original

201–210 of 260 posts

Re: The first stable release of a memory safe sudo implementation

#201

Post by infamouscow »

marcus0x62 wrote: post #190
godshatter wrote: post #120

Earlier quoted context omitted.

The features they are leaving out were presumably added for a reason. If someone is on a system that is using sudo-rs as a drop-in replacement (not under their control) and they need to use one of those less widely-used features, how secure is the work-around they have to use instead? I'm hoping this factored in to their analysis. Sometimes reimplementing something and leaving out lesser-used features to "reduce the…

Sure, and those people are free to continue to use the C-based implementation of sudo, implement the features themselves and submit patches to the maintainers of the rust sudo implementation, etc. But, the idea that a feature, once implemented, is sacrosanct and can never be deprecated is insane, especially for a piece of critical security infrastructure.

Having disdain for real-world business requirements is probably why Rust sees so little use in the real world.

Re: The first stable release of a memory safe sudo implementation

#202

Post by fanf2 »

_8j50 wrote: post #31

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.

2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156

2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634

Re: The first stable release of a memory safe sudo implementation

#203

Post by kelnos »

> 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.

Re: The first stable release of a memory safe sudo implementation

#204

Post by qerti »

adastra22 wrote: post #166
jvanderbot wrote: post #127

Earlier quoted context omitted.

Yes buffer overflows are one of the explicitly addressed vulnerabilities of Rust's bounds checker, which is always on, if memory serves. I haven't touched Rust in a year.

You can get around the bounds checker with unsafe code. But yes, by default an overflow should result in a panic and program termination.

This comment reminds me of “What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it…”

Re: The first stable release of a memory safe sudo implementation

#205

Post by kelnos »

vlovich123 wrote: post #137
yakubin wrote: post #89

Earlier quoted context omitted.

It's doable by opening the file in a privileged process (sudo) and passing the file descriptor to a non-privileged process. Maybe one could make a sudoedit that opens a file in sudo process and then spawns a non-privileged editor process which inherits the file descriptor and is given the /dev/fd/ path on the command line, so it stays none the wiser about the whole process.

Sounds like a bit of recipe for accidentally handing access to an unintended privileged fd through inheritance (ignoring the /dev/fd one) such that a compromised unprivileged SUDO_EDITOR value gives you sudo access. Maybe not likely, but I’d really be hesitant about any feature that relies on implicit fd inheritance…

Another option could be to open a UNIX socket in the privileged sudo process, spawn an unprivileged child process 'shim' that connects to that socket, and then the sudo process can pass the file descriptor over the socket. Since the child shim is 'clean', it should have nothing more than stdin/out/err open, plus now this passed FD. Then the shim can spawn the target program and allow it to inherit just the passed FD.

I think the larger issue is that I doubt many (if any?) editors allow opening a file via an inherited file descriptor! I guess some will read stdin (the shim could close stdin and then dup2() it into its place), but then there's no way to save the file back when finished.

Re: The first stable release of a memory safe sudo implementation

#206

Post by kelnos »

gary_0 wrote: post #55
tecleandor wrote: post #52

Earlier quoted context omitted.

Old XKCD joke (maybe coming from an older joke)... https://xkcd.com/149/

That XKCD joke was all over the Internet in 2006. Now get off my lawn.

Huh, it took 6 years for the joke to get added: https://github.com/sudo-project/sudo/commit/c1d6e86d67aa60d7...

Re: The first stable release of a memory safe sudo implementation

#207

Post by adastra22 »

qerti wrote: post #204
adastra22 wrote: post #166

Earlier quoted context omitted.

You can get around the bounds checker with unsafe code. But yes, by default an overflow should result in a panic and program termination.

This comment reminds me of “What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it…”

Look into the crates you use and you’ll find tons of unsafe code, especially around custom data structures doing buffer pointer arithmetic and stuff. If it’s wrapped in a safe interface, you’d never know.

Re: The first stable release of a memory safe sudo implementation

#208

Post by [deleted] »

wiz21c wrote: post #9
fdsfsdfdsffgg wrote: post #5

> 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).

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)

[deleted]

Re: The first stable release of a memory safe sudo implementation

#209

Post by AndyKelley »

coggs wrote: post #60

As one of the original creators of 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 pos…

By making it simpler and not having a ton of rarely used features, and by using a programming language that makes it more difficult to write bugs.

Re: The first stable release of a memory safe sudo implementation

#210

Post by ndriscoll »

jerf wrote: post #84
nolok wrote: post #67

Earlier quoted context omitted.

In memory safety ? Yes, the language is much better at being safe by default. But it does nothing for logics bugs. The thing is, replacing from C (sudo or anything else), the number of exploit due to null pointer or buffer abuse or ... represent easily 50% of it.

"But it does nothing for logics bugs." "Nothing" is too strong. It does not solve logic bugs, but type systems stronger than C can solve some logic bugs too. Even something as simple as having some concept of "private" and "public" and some boundaries between them can help. I'm writing some code right now in Go, hardly a super strong type system, but I've still put some basic barriers in place like, you can have a re…

C does have some notion of visibility: put private declarations into the .c file instead of the .h file and declare static linkage. You could have a function that returns a pointer to const for read only data. Obviously they can cast that away, but other languages have unsafe escape hatches too. C also has static analyzers to help with some classes of bugs.

Cowboy code might be common, but you don't have to do that. If using something C-like, C++ definitely gives you a lot more tools to write safe code (or hang yourself, up to you) though.

Post reply on HN