The first stable release of a memory safe sudo implementation
191–200 of 260 posts
Re: The first stable release of a memory safe sudo implementation
#192Having 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.
How else would you do things as root or superuser without exposing everything? If your sudo configuration is ALL = ALL (or is a variant of this), then sudo opens everything up for use/abuse. But if you carefully construct the configuration to allow only certain commands, it’s much better than just giving out the root password to users.
Nothing a user is supposed to do should require elevating to root to do.
>it’s much better than just giving out the root password to users.
This is even worse. Access control should be set up properly instead of having users assume the identity of other accounts.
Re: The first stable release of a memory safe sudo implementation
#193Earlier quoted context omitted.
Yes buffer overflows are one of the explicitly addressed vulnerabilities of Rust's bounds checker, which is always on, if memory serves. I haven't touched Rust in a year.
You can get around the bounds checker with unsafe code. But yes, by default an overflow should result in a panic and program termination.
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.
Re: The first stable release of a memory safe sudo implementation
#194Earlier quoted context omitted.
The borrow checker does not prevent out of bounds access of arrays (or vectors or whatever you want to call them). The borrow checker is intended to protect against "temporal memory unsafety". It can tell you that you are using something that has already been freed, or something that could be freed while you are using it for example. Bounds checking is a "spatial memory unsafety" problem, it has nothing to do with bo…
Does it not provide some protection against a buffer overflow?
Re: The first stable release of a memory safe sudo implementation
#195Earlier quoted context omitted.
Close all other fds between fork and exec then (you can look at the code of base::LaunchProcess in Chromium for an example). It’s a minuscule amount of code to audit compared to XDG portals. And it’s backwards-compatible with decades of unix programs. For a more complicated solution: spawn a zygote process early with a unix socket which you’ll use to send the fd later. Zygote at start drops provileges. When it receiv…
I’m not saying it’s not possible to do correctly. But do you not agree that the first is hard to correctly (can overlook an fd) while the latter is a lot of complexity? There is the CLOEXEC flag which is the intended way to manage this but it’s not the default and you have to be diligent about setting it which again carries its own set of challenges. What you’d really want is CLOEXEC implicitly on all fds and having…
Re: The first stable release of a memory safe sudo implementation
#196Sudo-rs' first security audit - https://news.ycombinator.com/item?id=38131442 - Nov 2023 (58 comments)
Re: The first stable release of a memory safe sudo implementation
#197Earlier 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…
Re: The first stable release of a memory safe sudo implementation
#198Earlier 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…
Re: The first stable release of a memory safe sudo implementation
#199Earlier quoted context omitted.
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 re…
> POSIX doesn't dictate an editor ed is the standard text editor!
Re: The first stable release of a memory safe sudo implementation
#200As 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…
So let's settle this. Does sudo rhyme with judo or voodoo?