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

101–110 of 260 posts

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

#101

Post by db48x »

quotemstr wrote: post #47
garblegarble wrote: post #3

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

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…

It’s actually mostly just a matter of time and money. They implemented the most commonly–used features first, because those are the most important ones. The majority of people could probably swap sudo-rs in for their existing sudo implementation today with nothing lost. Others will need one of those “enterprise features” and so they should either wait or pitch in.

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

#102

Post by tialaramex »

lionkor wrote: post #75
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.

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 makes it less vulnerable to these mistakes than some languages, but there is no magic. 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 (the "New type idiom"), and out of the box the Duration and the File Descriptor are in fact provided as distinct types. So, some improvement.

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

#103

Post by nindalf »

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)

But it wasn’t GPL to begin with - https://www.sudo.ws/about/license/

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

#104

Post by iudqnolq »

zorked wrote: post #58
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).

Kinda? Historically there were indeed concerns about reimplementation and copyright. One of the ways that the GNU Project tried to fight claims was to reimplement the tools using dynamically-allocated memory (instead of Unix's traditional fixed-size buffers) to make sure the implementation was sufficiently different. Other ways were making the implementation Posixly correct, adding internationalization or trying to p…

Arguably writing in Rust will force a similar magnitude difference to those examples. For example, you'll probably replace that modern sorting algorithm with a call to .sort

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

#105

Post by debugnik »

n_plus_1_acc wrote: post #51
Karellen wrote: post #34

Earlier quoted context omitted.

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

That's inherited from OCaml I think. https://www.ocamlwiki.com/wiki/Enum

I don't think so, OCaml consistently calls them "variant types". I don't know who wrote that page, but that wiki didn't even exist before September and it isn't endorsed by ocaml.org, so I suggest you don't consider it authoritative.

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

#106

Post by zigzag312 »

pbmonster wrote: post #56
zigzag312 wrote: post #14

Earlier quoted context omitted.

Is that really bad? You are free to not use such distributions. Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. GPL or no GPL.

> Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. That's why hashes are published by distributors and checked by package managers, right?

That only checks that binaries are the same as what is published by distributors.

It doesn't help against a malicious distributor, unless package managers also do a deterministic build themselves and verify that checksum from self-build binary matches the checksum published by a distributor.

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

#107

Post by cyber_kinetist »

I think the two bullet points they listed for their project (other than using Rust) are often overlooked:

- Leaving out less commonly used features so as to reduce attack surface

- Developing an extensive test suite which even managed to find bugs in the original sudo

Which are the most important aspects when writing any safety-critical code, even moreso than rewriting in Rust!

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

#108

Post by josefx »

codetrotter wrote: post #71
garblegarble wrote: post #25

Earlier quoted context omitted.

That seems like the Right Way to do it... As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.

> As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it. In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root. And then when I want to run my script, I run it as root doas…

I just constantly run as root since there is always a chance that I might need root permissions for something. /s

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

#109

Post by 0xbadcafebee »

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]

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

#110

Post by cyber_kinetist »

timschmidt wrote: post #91
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.

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.
Post reply on HN