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

121–130 of 260 posts

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

#121

Post by khimaros »

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…

i wonder what fraction of these fixes came with automated texts to prevent regressions (and to aid new implementations from making the same mistakes).

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

#122

Post by kristjank »

PrimeMcFly wrote: post #76
mprovost wrote: post #19

Earlier quoted context omitted.

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.

OpenBSD is mainly used by hobbyists and not sysadmins, which is why there are not complaints about the missing functionality.

OpenBSD is mainly used where other Unices can be used, and provides widely used software like OpenSSH, OpenBGPD and OpenSMTPD. To say that it's a hobby project strikes me as very ignorant. That said, it is not very easy to convince the developers that a function is missing because it's a pretty opinionated project, and they might not share the user's definition of needed functionality. Thankfully, they're nowhere near ebassi levels of functionality deletion disorder.

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

#123

Post by steveklabnik »

antoinealb wrote: post #119
cyber_kinetist wrote: post #110

Earlier quoted context omitted.

Even if I don't like the design of Rust's borrow checker I still do appreciate how Enums/Option/Result types and pattern matching can make your code more robust. Really wish I can bring some of them to C++... I frequently use a poor-man's version of Result types with a `TRY()` preprocessor macro, but I'm often jealous of what Rust has in its toolbelt.

Isn't Rust's result type basically the same as Abseil's Status, or am I missing something ? https://abseil.io/docs/cpp/guides/status

Generally the same idea, yes. Your parent mentioned a key difference though: "and pattern matching." enums in Rust have much stronger language support.

But there are also differences, for example, errors must be absl::StatusCode, whereas enums in Rust allow for arbitrary error payloads.

Also don't discount ecosystem usage: everyone uses Result in Rust, abeseil isn't used by most things, and std::expected has its own issues (though I can appreciate how tough making those calls is) and only landed in C++23, so it's not as widely used as Result either.

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

#124

Post by yjftsjthsd-h »

guerrilla wrote: post #81
slacka wrote: post #49

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

I wonder how we are from a Rust UNIX userland. At least we wouldn't have to implement a C compiler!

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

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

#125

Post by kstrauser »

ajuc wrote: post #96
timschmidt wrote: post #91

Earlier quoted context omitted.

Enums, Option and Result types, absence of null, not to mention that the type system, borrow checker, and static everything by default, rewards encoding application state and state transitions using all these mechanics, such that they can be verified at compile time. I'd say the language does quite a lot to address logic bugs as well as memory safety. It can't protect a determined developer from themselves, but it pr…

Static-everything is such a gimmick in my opinion. It sounds great until you try to do something useful with your code. It's almost never the case that people actually want to hard-code stuff in the source code. Almost always you read configuration files at run-time (like sudo does) and change your behavior depending on run-time information - so you will have run-time errors.

“Static” here means that variables are const by default, and you can’t modify one without explicitly marking it as mutable.

In your case, a config object would be mutable inside the function that loads it from disk into memory, then read-only everywhere else by default.

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

#126

Post by ndr »

tptacek wrote: post #99
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…

Whatever else happened in those 43 years, we had a widely-exploitable memory corruption vulnerability (Baron Samedit) as recently as 2021.

And it looks like it was a buffer overflow:

https://blog.qualys.com/vulnerabilities-threat-research/2021...

Would Rust prevent this?

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

#127

Post by jvanderbot »

ndr wrote: post #126
tptacek wrote: post #99

Earlier quoted context omitted.

Whatever else happened in those 43 years, we had a widely-exploitable memory corruption vulnerability (Baron Samedit) as recently as 2021.

And it looks like it was a buffer overflow: https://blog.qualys.com/vulnerabilities-threat-research/2021... Would Rust prevent this?

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.

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

#128

Post by Hedepig »

ndr wrote: post #126
tptacek wrote: post #99

Earlier quoted context omitted.

Whatever else happened in those 43 years, we had a widely-exploitable memory corruption vulnerability (Baron Samedit) as recently as 2021.

And it looks like it was a buffer overflow: https://blog.qualys.com/vulnerabilities-threat-research/2021... Would Rust prevent this?

Yes it would be prevented by the borrow checker.

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

#129

Post by zokier »

hannob wrote: post #28
lynx23 wrote: post #4

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.

Do you use doas on Linux? It is not protected against tty pushback attack: https://github.com/Duncaen/OpenDoas/issues/106 That's a pretty severe unsolved security issue.

It's solved; TIOCSTI is disabled by default since Linux 6.2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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

#130

Post by steveklabnik »

ndr wrote: post #126
tptacek wrote: post #99

Earlier quoted context omitted.

Whatever else happened in those 43 years, we had a widely-exploitable memory corruption vulnerability (Baron Samedit) as recently as 2021.

And it looks like it was a buffer overflow: https://blog.qualys.com/vulnerabilities-threat-research/2021... Would Rust prevent this?

> Would Rust prevent this?

This is often hard to say.

In a very literal sense, you could write this same code, in unsafe Rust, so one could argue that Rust does not prevent it.

Some may argue that if this program was written in Rust in the first place, "concatenate all command line arguments into one big string for processing" wouldn't be the way you'd go about escaping command line arguments. The issue here is about misplacing a null terminator, Rust strongly prefers a "start + length" style of representing strings instead of null terminators, so you'd never really end up in this situation in Rust in the first place.

I'm sure there's other ways to evaluate the situation as well. Which one you find compelling is up to you.

Post reply on HN