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

111–120 of 260 posts

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

#111

Post by shakow »

bunderbunder wrote: post #100
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.

This gets said a lot, but I am coming to believe that the case is overstated. For two reasons: 1. Valgrind exists. It's not perfect, but it does arguably do a pretty good job as long as you're writing modern C. The biggest gap I'm aware of is that it can't really help you with global pre-allocated buffers. But I don't think that any language or tool can effectively protect you from information leakage if you're doing…

> Valgrind exists

You may be right on an infinite frictionless plane, but unfortunately that does not work in real life, cf. e.g. https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-sy...

> Memory-safe is not the same thing as secure.

And safety belts do not help you if your car is on fire, still it's better to wear it.

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

#112

Post by SoftTalker »

folmar wrote: post #85
noahjk wrote: post #64

Earlier quoted context omitted.

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?

> sudo seems fairly straightforward `su` is straightforward, `sudo` is a very powerful piece of software and the configuration has a lot of edge cases.

Yes, have a read of the sudoers man page and marvel at the complexity of the configuration, and wonder about your chances of getting it right if you are not well-experienced. This is the config file with the infamous paragraph:

The sudoers grammar will be described below in Extended Backus-Naur Form (EBNF). Don’t despair if you are unfamiliar with EBNF; it is fairly simple, and the definitions below are annotated.

OpenBSD replaced sudo with their own "doas" command a few years ago; the doas.conf manual page is about 100 lines; sudoers is over 2,000.

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

#113

Post by lambdaone »

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.

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

#114

Post by brundolf »

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

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

#115

Post by Someone »

tialaramex wrote: post #102
lionkor wrote: post #75

Earlier quoted context omitted.

Is that because theyre easy to find, or because theyre the worst?

A lot of the most serious security vulnerabilities are memory safety because e.g. remote code execution is very often along the lines of "LOL, I smash buffer with machine code, it gets executed" and that's a memory safety problem. For sudo you have potential for some very serious logic bugs, where the program does exactly what the programmer wrote, but what they wrote was not what they intended. Rust's type safety ma…

> In C obviously a UID, a PID, a duration, an inode number, a file descriptor, a counter are all just integers. In Rust you could make all those distinct types

For various kinds of IDs you can do that in C, too:

  struct UID {
    int value;
  };
A C compiler can pass these in registers to functions (https://wintermade.it/blog/posts/value-struct.html). So, performance impact should be zero.

It may be not as nice as other languages, but it isn’t bad, either. If you use C++, it can be made a bit nicer, and you could also have such structs that you can calculate with.

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

#116

Post by steveklabnik »

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]

> Recently a Rust sudo replacement (maybe this one?) got a security audit.

It is the same one. It's weird because, this article is from August. But the one you're referencing is from three days ago: https://ferrous-systems.com/blog/sudo-rs-audit/

> the severity was worse in the Rust version.

I am unsure where you got this. It's the same vulnerability.

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

#117

Post by mhh__ »

oynqr wrote: post #63
tsimionescu wrote: post #40

Earlier quoted context omitted.

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

Pretty sure you'd have to clean room the whole thing. Which these Rust implementation might not have. This is not legal advice.

I can't remember enough to name names but one obviously didn't to the point that it mentioned what the GNU code does in comments.

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

#118

Post by steveklabnik »

brundolf wrote: post #114

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 Obviousl…

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.

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

#119

Post by antoinealb »

cyber_kinetist wrote: post #110
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…

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

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

#120

Post by godshatter »

marcus0x62 wrote: post #93
quotemstr wrote: post #47

Earlier quoted context omitted.

There's a gulf between being 99% compatible with something and being a 100% drop-in. If the author of program B wants to replace A, he should go the extra mile and implement every feature of A so as to erase technical excuses for stasis. B needs to put aside his ego, swallow his pride, and implement all the features of A, even the ones her personally dislikes, because the effect of doing otherwise will be that B does…

Perhaps, but if the goal is security of a critical tool, losing some attack surface (features) if they aren’t widely used is a win. Other projects, like ntpsec[0] have taken this approach with good results. Although, I agree with another commenter in this thread[1] that this effort would have been better directed at something with an inherently small attack surface like doas. 0 - https://www.ntpsec.org/accomplishment…

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 attack surface" can sound an awful lot like "let them pound sand".

Post reply on HN