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

161–170 of 260 posts

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

#161

Post by empath-nirvana »

0xbadcafebee wrote: post #109
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…

[flagged]

> It not only had the same security vuln that hit the non-Rust version

The audit of the rust version is how they discovered the vulnerability in the C version.

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

#162

Post by kstrauser »

GTP wrote: post #155
kstrauser wrote: post #125

Earlier quoted context omitted.

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

If your program doesn't have a way of reloading its configuration at runtime, then even that first object created by reading the configuration from file can be immutable.

Yep! What I mean, though, is that the loading function itself will need to mutate the object as it reads settings from disk and updates the in-memory data structure. Once that's done, you can pass that around as a read-only object.

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

#163

Post by kstrauser »

ajuc wrote: post #152
kstrauser wrote: post #125

Earlier quoted context omitted.

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

I use rust, and it does have static by default in many places (for example it's hard to do the traditional OOP virtual polymorphism or to keep objects of various types in one container) and it makes it pretty hard for me to write "nice" looking code. It usually devolves into a lot of nested if-else and switch (match) instructions.

I haven't run into that so much myself. What I have run into is trying to write C-but-in-Rust, for which the compiler yells at me to please knock it off. It got way easier when I gave up and committed to doing things the Rust way.

Not saying you haven't done that, just sharing my personal experience with it.

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

#164

Post by alpaca128 »

0xbadcafebee wrote: post #109
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…

[flagged]

> Like building an entirely new car company around only making side-impact collisions safer

...which still results in safer cars overall, so I don't see the problem. Especially if those cars are almost completely immune to side-impact collisions and if it's actually not a car company but a technology every manufacturer can use for future products.

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

#165

Post by AnonC »

charcircuit wrote: post #133

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.

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.

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

#166

Post by adastra22 »

jvanderbot wrote: post #127
ndr wrote: post #126

Earlier quoted context omitted.

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.

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

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

#167

Post by adastra22 »

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

Sibling comment mentioned pattern matching, but didn’t point out the important point that the rustc compiler makes sure all patterns matches are exhaustive.

To use a C example, if you add a new definition/variant to an enum, suddenly all switch statements over that enum will fail to compile (unless there is a default: branch).

This does eliminate a large swatch of logic errors, though by no means all.

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

#168

Post by [deleted] »

Calzifer wrote: post #159
sgerenser wrote: post #140

Earlier quoted context omitted.

It can eliminate many bugs, but it certainly wouldn’t eliminate all bugs. During implementation they realized they were not implementing sudo’s (undocumented) feature of failing to run if the sudoers file is world-writable: https://ferrous-systems.com/blog/testing-sudo-rs/ . Of course they did find and fix the bug, but in general Rust isn’t going to protect you from bugs like this that are essentially logic errors.

That is documented. Since the mercurial web interface isn't very nice to use I picked a random version. sudo 1.8.6 from 2012 writes in the man page "The sudoers file must not be world-writable,". https://www.sudo.ws/repos/sudo/file/SUDO_1_8_6/doc/sudoers.m... This is also a very common behaviour for security sensitive applications to check config file permissions. Another example I remember are ssh private keys. I mi…

[deleted]

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

#169

Post by sgerenser »

Calzifer wrote: post #159
sgerenser wrote: post #140

Earlier quoted context omitted.

It can eliminate many bugs, but it certainly wouldn’t eliminate all bugs. During implementation they realized they were not implementing sudo’s (undocumented) feature of failing to run if the sudoers file is world-writable: https://ferrous-systems.com/blog/testing-sudo-rs/ . Of course they did find and fix the bug, but in general Rust isn’t going to protect you from bugs like this that are essentially logic errors.

That is documented. Since the mercurial web interface isn't very nice to use I picked a random version. sudo 1.8.6 from 2012 writes in the man page "The sudoers file must not be world-writable,". https://www.sudo.ws/repos/sudo/file/SUDO_1_8_6/doc/sudoers.m... This is also a very common behaviour for security sensitive applications to check config file permissions. Another example I remember are ssh private keys. I mi…

Interesting, the posting I linked to indicated this behavior wasn’t documented. It’s certainly not surprising and as you mentioned, it’s equivalent to openssh requiring specific permissions on private key files.

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

#170

Post by declan_roberts »

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.

Post reply on HN