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

231–240 of 260 posts

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

#231

Post by Terretta »

cyber_kinetist wrote: post #107

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!

Are those more important than, say:

- Proven with Coq, a formal proof management system: https://coq.inria.fr/

See in the real world: https://aws.amazon.com/security/provable-security/

And check out Computer-Aided Verification (CAV).

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

#232

Post by emporas »

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

So, statically link the new sudo with the old sudo, and when the user tries to use less commonly used features fallback to the older version in C.

The binary executable will be bigger, but disk space is a lot cheaper nowadays, compared to 43 years back.

I mean, is there any time where one more level of indirection failed to make everyone happy?

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

#233

Post by charcircuit »

thebitstick wrote: post #229
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.

I disagree. Desktop users run a lot of untrusted software. Allowing software to gain Administrator privileges with a single click from the user is a mistake. It doesn't follow the principle of least privilege where the user should only give apps permission for what they need to do and not more.

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

#234

Post by timschmidt »

bunderbunder wrote: post #228
chlorion wrote: post #185

Earlier quoted context omitted.

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

Even unsafe Rust comes with significantly more checks and safety built-in than C.

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

#235

Post by mtlmtlmtlmtl »

kstrauser wrote: post #163
ajuc wrote: post #152

Earlier quoted context omitted.

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.

One of the habits I struggled to get rid of at first was the habit of making lots of things in structs refs for no reason, where it would be typical kn C for C reasons.

This led to a lot of unnecessary friction with the borrow checker while I was still getting to understand it.

Once I started always asking myself "does this really need to be a ref?", things became much easier. And this in turn revealed itself as a useful rule of thumb for keeping coupling between subsystem in check.

Then I was doing some C work and I realised I was asking the same question to myself about pointers too. And I found it could often reduce cognitive load down the line, because I'd end up in much fewer situations where I'd have to figure out "who should free this, and when?".

That's when I realised this cognitive load of keeping the borrow-checker happy was always there in C too. It was just more diffuse, and invisible until it blew up in my face. And when it did it was in the form in nasty runtime problems, not a helpful compiler error that happened before the code was even checked in.

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

#236

Post by mtlmtlmtlmtl »

bunderbunder wrote: post #228
chlorion wrote: post #185

Earlier quoted context omitted.

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

I feel pretty good about the fire safety measures at my apartment despite the fact that I own several lighters.

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

#237

Post by Too »

bunderbunder wrote: post #228
chlorion wrote: post #185

Earlier quoted context omitted.

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

I’d rather have safety default on with an opt-out, rather than the inverse that C gives you with -Werror -Wall -Weverything -Wyesireallymeanteverything. Compile it again one two different architectures, compile yet another time with clang-tidy and then static analysis with Coverity just to be sure. Run it with valgrind, asan and thread sanitizer. Sprinkle some fuzz testing on top.

Yet you still don’t the same level of confidence as a rust program that may have a small unsafe block in one corner of the code.

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

#239

Post by Too »

Terretta wrote: post #231
cyber_kinetist wrote: post #107

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!

Are those more important than, say: - Proven with Coq, a formal proof management system: https://coq.inria.fr/ See in the real world: https://aws.amazon.com/security/provable-security/ And check out Computer-Aided Verification (CAV).

A formal proof is only as good as its requirements. Leaving out features and reducing complexity is for sure going to be more secure.

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

#240

Post by viraptor »

Someone wrote: post #115
tialaramex wrote: post #102

Earlier quoted context omitted.

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

It exists, but... throw in some macros or generic cache/storage which is untyped and you end up with a non-trivial version of this:

    struct GID gid = *(GID*) &some_uid;
Which will compile without issues or warnings by default. No belts or braces in this area.
Post reply on HN