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

141–150 of 260 posts

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

#141

Post by thiht »

lambdaone wrote: post #113

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.

As they say in the article, their test suite was even able to uncover 2 bugs in the original sudo. That's definitely a win.

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

#142

Post by PrimeMcFly »

kristjank wrote: post #122
PrimeMcFly wrote: post #76

Earlier quoted context omitted.

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

> OpenBSD is mainly used where other Unices can be used,

That's a pretty general statement, and I'd say to that not really. It's very much a hobbyist OS. A few people use it at home as firewalls, a few small businesses maybe, but it's mostly hobbyists and developers.

> To say that it's a hobby project strikes me as very ignorant.

I mean, I've been familiar with the project for over 20 years, so I don't think I'm ignorant at all. The developers primarily make the OS for themselves and people with the same ideas and priorities.

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

Right, the devs prioritize their own needs, and can do so because it's a hobbyist OS.

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

#143

Post by NegativeK »

pjmlp wrote: post #37
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).

For better or worse the use of GPL is going away, even the future of Linux kernel is not guaranteed. In the realm of IoT FOSS UNIX like operating systems, all the contendants are using a mix of Apache, MIT and BSD licenses, including the ZephyrOS sponsored by the Linux Foundation. When the GPL generation is gone from the face of the Earth, it won't last long that UNIX-like OSes get another steward alternative to the…

How would they be able to drop the GPL from the Linux kernel?

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

#144

Post by ralgozino »

coggs wrote: post #66
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?

Hackaday interviewed me about the origin story - https://www.youtube.com/watch?v=LaAwl3HN5ds&ab_channel=HACKA...

great story! also, TIL that I've been pronouncing `sudo` wrong, I was 100% sure that it was supposed to be like pseudo, but I guess that is a myth :)

It's so great to be able to listen and learn from the people that invented these important building blocks themselves, I feel lucky. Thanks for sharing.

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

#145

Post by nonameiguess »

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!

I looked into this a few years back when I was making my own toy Linux distro, and this is the list of packages provided by a typical GNU system that meet POSIX requirements for a userspace:

* `bash`

* `bc`

* `binutils`

* `bison`

* `Coreutils`

* `Diffutils`

* `file`

* `Findutils`

* `flex`

* `gawk`

* `glibc`

* `grep`

* `tar`

* `gzip`

* `M4`

* `make`

* `man-db`

* `man-pages`

* `procps-ng`

* `psmisc`

* `sed`

That's a reasonable start, but you also need, minimally, something to replace `pciutils`, `IPRoute2`, a bootloader, and an init system. For a close to expected experience, add in `TexInfo`, `XZ`, `ZStd`, and `bzip2`, plus `shadow` if you don't want passwords stored in plaintext.

POSIX doesn't dictate an editor, but you probably want something that can run in a terminal. Usually `cURL` and either `openssl` or `GnuTLS`, plus `bind-utils`, `ldns`, or something equivalent are there for actually using the network, something to replicate `gpg` functionality if you're going to install signed packages, and of course the package manager itself. Cargo is fine for Rust app developers, but can't replace an installer of system packages. You likely need an `ssh` implementation to replace `OpenSSH`.

I'm sure there's more I'm missing, but this is pretty close to what you'd get in a minimal server image.

If you're looking to fully get rid of C and not need a C compiler, though, Linux itself is a hurdle. You don't necessarily need a kernel quite as fully-featured, but you need something that at least implements the POSIX system calls. Just about every Linux distro I'm aware of seems to also provide Python and Perl these days as a whole lot of system utilities and build scripts use them. Presumably, rewriting all of Perl and Python in Rust is not feasible, so you either need some other interpreted scripting language good for system scripting that is written in Rust, or somehow make your shell a superset of POSIX but also much closer to a real programming language.

Don't underestimate the lift of replacing `libc`, either. It's not just the C standard library and interface to system calls. It also provides the linking loader that makes it possible to even run other programs, all of the locales and time zones, the system's name server, profiler, memory dumper. A whole lot of stuff.

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

#146

Post by mustache_kimono »

mhh__ wrote: post #117
oynqr wrote: post #63

Earlier quoted context omitted.

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.

I'm really not certain this is enough to be a copyright problem.

For instance, GNU and POSIX both publish their specs for the coreutils. If a coder were to take a look at the actual GNU code (which BTW is published for everyone to see), copyright law has a well trodden distinction between the idea and the expression -- that is, ideas are not copyrightable. If the "idea" simply amounts to what would be a more a detailed specification, I'm not sure there is a problem, like ... GNU uses this kernel facility for X. The problem would be vast amounts of "expression", especially "creative expression", directly copied and reimplemented in Rust. If the code is meat and potatoes, not 10xer galaxy brain fare ("I wrote a custom allocator which is suspiciously like the custom allocator implemented by GNU"), there shouldn't be an issue.

Think about what copyright to a play, or a novel, or a screenplay is. Now imagine a comment in the text/source: "This is how Toni Morrison did her characterizations in Beloved". This obviously isn't a copyright violation, unless you're copying the actual expression or a translation of the actual expression found in Beloved.

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

#147

Post by aumerle »

hpb42 wrote: post #23
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...

One of those left out features is `sudoedit` or `sudo -e`. I use this a lot when editing files in /etc or any file that my user does not have permissions. The flag first copies the file to a temporary location with permissions for my user to edit, then opens my text editor (defined via $SUDO_EDITOR env var) as _my user_, without any sudo permissions. After I close the editor, the file is copied back with the original…

So now any program that's running as your user, even your browser, can edit any file you edit with sudo. It just has to watch for your editor to quit and win a race with sudo to modify the file before sudo reads it.

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

#148

Post by grayhatter »

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…

Thank you for working to create one of the tools which is obviously on the list of the most valuable and beneficial to computer security. Perhaps only second to netfilter.

And I'm really sorry so many people have decided they're going to imply something is wrong or broken with it for their own clout. Or because they've bought into the lie that no code written in C can be safe or correct.

For what it's worth, I and all the engineers I willingly associate with (read: the ones who I respect) all have said the exact same thing. Switching to rust here, just 'cause, isn't going to meaningfully increase anyone's security. But what are you gonna do. Other than ask people to be honest?

Annoying fanboys aside... again, *thank you*! The computer security world is meaningfully better because of your work, and that's something the RIIR fad will never be able to replace :)

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

#149

Post by adgjlsfhk1 »

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…

The fundamental problem with valgrind is it only looks at what happened, not what could happen. Valgrind is great at making sure you don't have memory safety issues for "normal" inputs, but is basically useless at making sure your code doesn't have memory safety vulnerabilities when fed atypical inputs.

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

#150

Post by guerrilla »

yjftsjthsd-h wrote: post #124
guerrilla wrote: post #81

Earlier quoted context omitted.

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

Well, I guess if the build system uses that distro or if it's a sourve distro.
Post reply on HN