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

221–230 of 260 posts

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

#221

Post by happymellon »

stouset wrote: post #215
djbusby wrote: post #26

Earlier quoted context omitted.

I'm still mad I can't just `tail -f`

journalctl -f On the flip side, now you get structured logging, efficiently-searchable logs over any of those fields, the ability to easily aggregate logs from multiple machines, the ability to accurately iterate over logs in processes without missing entries, and on and on and on. Logs as a database is wildly superior to logs as a plain text file, with virtually the only downside being that you need a specific progr…

> the only downside being that you need a specific program to tail them.

The journal can output to text files as well!

But this is exactly it, my only issue is the ideological one that there is no spec for the database. The implementation is the specification, so the only true way of building a reader of logs is to implement the journal. There are attempts to document the layout but if there is any difference then you can't submit a bug to get the layout corrected but the implementation isn't wrong.

I can think of plenty of other applications with bigger issues than that. But I think can still want the defacto log for Linux to have an official spec.

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

#222

Post by jjgreen »

kristopolous wrote: post #220
jjgreen wrote: post #200

Earlier quoted context omitted.

su(peruser) do, so soodoo

Language isn't necessarily that logical. It can be whatever he says it is.

Language will evolve as it will, the person who invents a word does not get to tell the world how it will be pronounced for the rest of time.

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

#223

Post by marcus0x62 »

infamouscow wrote: post #201
marcus0x62 wrote: post #190

Earlier quoted context omitted.

Sure, and those people are free to continue to use the C-based implementation of sudo, implement the features themselves and submit patches to the maintainers of the rust sudo implementation, etc. But, the idea that a feature, once implemented, is sacrosanct and can never be deprecated is insane, especially for a piece of critical security infrastructure.

Having disdain for real-world business requirements is probably why Rust sees so little use in the real world.

That’s an interesting criticism. With commercial projects I’ve been involved in, feature deprecation was always based on a business case built on cost vs future revenue projections, not on a sense of duty to maintain ever single feature forever, regardless or whether or not anyone actually used it.

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

#224

Post by bombcar »

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…

It sounds like 90% of "sudoedit" can be done without elevated permissions, assuming your user can read the file.

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

#225

Post by kristopolous »

jjgreen wrote: post #222
kristopolous wrote: post #220

Earlier quoted context omitted.

Language isn't necessarily that logical. It can be whatever he says it is.

Language will evolve as it will, the person who invents a word does not get to tell the world how it will be pronounced for the rest of time.

Cool I'll pronounce it ghoti then

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

#226

Post by jjgreen »

kristopolous wrote: post #225
jjgreen wrote: post #222

Earlier quoted context omitted.

Language will evolve as it will, the person who invents a word does not get to tell the world how it will be pronounced for the rest of time.

Cool I'll pronounce it ghoti then

Your grandchildren may

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

#227

Post by sophacles »

larodi wrote: post #212
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…

Of course it's not. But hubris is possible and does not take years to master. And honestly statements like my overnight-rust-sudo is better than some poor peoples 40 years of work... well they don't really help Rust becoming more popular, but actually contribute to everything rust becoming even more irritating. Most rust tools are released with this pathos of "we fix what oldies couldn't get right with C". Not a grea…

Who said anything about "overnight"? This project has been worked on for a year, implemented a test suite that found bugs in the original sudo, and have generally been respectful of the original work.

I think you might be projecting something here, there's no evidence for for your assertions.

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

#228

Post by bunderbunder »

chlorion wrote: post #185
bunderbunder wrote: post #100

Earlier quoted context omitted.

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…

It's true that it doesn't eliminate all bugs in general, but it can completely eliminate buffer overflows for example. There is no excuse to not at least have bounds checking. This is one of the most basic memory safety problems and it's trivial to prevent. Just preventing this small issue will prevent a non-trivial fraction of bugs. I don't have sudo's bug list on hand but I wouldn't be surprised if 25% or more are…

> You can't switch them off.

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

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

#229

Post by thebitstick »

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.

On a server, absolutely. On a desktop, the user is usually the administrator anyways. UAC exists on Windows land and the Administrator account is disabled for a reason.

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

#230

Post by bunderbunder »

Filligree wrote: post #193
adastra22 wrote: post #166

Earlier quoted context omitted.

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

You can , but unsafe code is discouraged in general, even given a slight performance cost. For performance-insensitive, security-critical code, there really shouldn't be any such code in the entire program—and it would be easy to verify that with a presubmit.

In an ideal world, no, there shouldn't. But `unsafe` is not just a performance hack; people do find things that they legitimately need to do that Rust can't statically verify. Probably the most trivial example is interacting with code that is not itself written in Rust.

This does imply that some of the stronger claims about Rust's level of static safety guarantees that float around on the Internet can't really be true unless substantially everything you might want to do has a version that's been completely written in Rust. Whether you feel that means that achieving the desired level of safety implies you've still got to rely on some dynamic analysis tools just to be sure probably depends on how much safety you really want, and how much faith you're willing to place in the skills of the authors of the libraries you use.

And even then, if we really want to go least common denominator, if you're running your program on Windows or a Unix or basically any other OS that isn't Redox, then you've got unsafe code executing every time Rust's own standard library needs to make a syscall to achieve something.

Which I don't say by way of criticizing rust Rust. It's got to live in the same crappy world we all have to live in, and it's arguably doing a better job of de-crappifying it than any other systems programming language. I'm just trying to illustrate how an unqualified statement along the lines of "there shouldn't be any unsafe code in the entire program" is kind of a self-strawman, precisely because Rust has to live in said crappy world, and I think that it might be unsafe to lose sight of that fact.

Post reply on HN