Fair enough but what do you recommend?

Me, I try to keep people out of my systems that I don't trust. This particular snag needs local access but I will grant you that my web server or other exposed service might provide a local interface.

Instead of throwing your hands up and screaming "crap" you do your risk assessment and attempt to mitigate as best you can. I read a lot of blogs and have a fair amount of logging and analytics lying around the place (and that's just at home).

Fairly recently I found that my wife's car had loose nuts on the front nearside wheel. That was a change to fix a worn tyre for obvious safety reasons but for whatever reason the fixings were not done up properly. I think they were done up finger tight but a distraction caused the mechanic to forget to use a spanner (wrench) to finish the job to spec. The wheel seemed to work fine but you would get a low rumble sound on corners. It was not a trivial to diagnose fault because you had to notice it before failure - I'm a (non chartered) Civ Eng and IT bod but not a mechanic. There is a minimally screwed on plastic cover that stopped the bolts from flying out - not much.

A car wheel is a thing we can all look at and see that the four bolts are not working properly, once you remove the plastic cover and see them wobble.

Now that is what you can do to protect yourself (risk assess, mitigate etc.) However there should also be something that protects "civilians" and I think that is what is missing. I'm not too sure how we do that.

Longer: One of two things -

1. Choose the most boring software possible, trust that the process will work as expected and that you're no worse off than anyone else. Update your software regularly

2. Choose the simplest, most robust software possible (Alpine, OpenBSD, etc). In this case, doas instead of sudo. Pray that works better than everyone else or that you get some benefits through obscurity. Still get surprised every so often. Update regularly

Either way, modern software has gotten complex enough that there's few options for the average person

why do you need to have sudo? I'm perfectly fine without it. sudo is maybe useful in the case where others on the system don't need to know the a password to run as someone else (including root) but need to be able to do that anyway. sudo seems to have gotten a big installation bases through ubuntu and everybody thinks it's normal now, but really for me it's not.

If you only want to allow specific units the authorizer is passed the unit under `action.lookup("unit")`.

MirageOS unikernels like were mentioned yesterday? Get away from running network services on Linux entirely?

How so? The OCaml compiler is written in OCaml and bootstraps itself.

Personally, while I doubt these are the case, having never heard of MirageOS before, I'm willing to be proven wrong. However, if the answer to any of these is "no", I have a hard time seeing how "just abandon Linux wholesale for NewShinyThing" is a viable option for more than a tiny subset of users. (Even if they're all "yes", it's still a wildly unrealistic expectation...)

No, of course not; the only thing that supports everything that Linux supports is Linux. But most use cases don't use every part of Linux.

> Is there a robust ecosystem of MirageOS users online able to help troubleshoot issues from the simple to the arcane?

I doubt it, but how do we get to there from here except by more users starting to use it?

> Is it supported by VPS providers the world over?

Yes, since what you build is just a VM image.

> However, if the answer to any of these is "no", I have a hard time seeing how "just abandon Linux wholesale for NewShinyThing" is a viable option for more than a tiny subset of users. (Even if they're all "yes", it's still a wildly unrealistic expectation...)

I don't disagree as such, but I do think that at this point building anything on these insecure foundations is throwing good money after bad / building castles on sand. Probably 95% of the time you build something that serves your present business purposes, accept a certain amount of insecurity, and get on with your life. But it's worth putting a bit of effort into looking for better ways to do things.

"The PR does not include tests" is not the same as "nobody performed any tests" is not the same as "nobody actually noticed a bug".

And of course, it's perfectly reasonable to form beliefs about code from reading it.

Broadly yes, but it would be hubris to claim you can tell the correctness of all code from merely looking at it.

Coding is not brute forcing. I feel like this is taking an extreme position at the complete opposite end from not testing anything.

EDIT: Misread the comment I replied to. I agree that it is not likely that anyone can tell the correctness of all code from merely looking at it.

It just seems SO EASY to add a test for this problem, literally the relevant test input is one slash by itself, or any string ending in a slash! So simple! If I sent a change like this at work, no matter how trivial, that said it fixed this bug but I didn't send any tests, the reviewer would reject it out of hand or, probably, just silently ignore my change. But that's the real problem here. This program is a monograph. There are no reviewers and there are, consequently, no standards.

You can get started here: https://google.github.io/oss-fuzz/

Folk love to bring up "responsibility" and all of that, but you can't really expect people to bear the responsibility of the world on their shoulders for their spare time projects. It's neither realistic nor fair.

OpenBSD replaced sudo with doas (http://man.openbsd.org/doas) in 2016 (https://www.infoworld.com/article/3099038/openbsd-60-tighten...). It’s a safe bet it’s more secure than sudo.

However, I do want to see programming as a culture adopt a higher standard when it comes to checking their work, and I think the continued prevalence of bugs like this are an indicator that we actually need to do so. I'm not asking for NSA-proof because that's not reasonable. But memory safety is a solved problem, and we need to be putting in the legwork to make more of our stack memory safe.

Not wearing a seatbelt when at work or in your spare time is irresponsible.

Writing code, without tests, that others use (and for security at that) is irresponsible.

But this is frakkin sudo we're talking about.

It's a wonder that anything works, ever.

Reading the code of important open source projects is not for the faint hearted!

> THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

If you don't like this license, you're free to use other software.

Nothing, as far as I can see. If someone writes some crappy security software and hides behind a licence that only means those relying on it have joined them in being irresponsible. Responsibility multiplies, it’s not zero-sum.

There is a large disconnect here.

You can choose to run this code, or you can choose not to run this code. It's really up to you.

This is very different from a sealbelt, as I can't choose to not have an accident with you, potentially causing a needless fatality.

You can choose to wear this seatbelt, or you can choose not to wear this seatbelt. It's really up to you.

I don't want to come across as pedantic - the point I mean to make is that I think a lot of people use sudo without thinking about it much. Sudo's just "the way to use linux" for a lot of people I know.

I don't think the sudo contributors should be labelled as irresponsible, because everything they've added to the project is available for the public to see and scrutinise. I don't think they've ever mislead people; rather that people have assumed things.

Maybe people who care about security will notice now that sudo doesn't have comprehensive testing, and will make their own alternative.

I know this is not exactly what you're trying to say, but it is what it comes down to.

So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release. If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide.

Have you seen something along those lines?

Kindly go to the source repository.

> If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide. Have you seen something along those lines?

That's what a TODO file is for. There is one you can browse to here: https://www.sudo.ws/repos/sudo/file/tip/TODO

There is also literally a dozen lines in the LICENSE file saying that the software is not quite production ready (THE SOFTWARE IS PROVIDED "AS IS") and should not be relied upon (THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS).

It's all spelled black on white, not sure what you would want more from the author?

> people can do in their spare time whatever they want, including writing code without tests

I did not refer to the Sudo project at all, so you might want to redirect your post to someone who did.

Then do it! On your own time, rather than complaining that someone else didn't do it on theirs!

Code review can work, but often it doesn't. There are countless examples of projects with "strict" review requirements that have similar issues (whereas qmail only had one).

Writing tests is the important thing, it keeps you honest.

https://github.com/sudo-project/sudo/graphs/contributors

That’s one maintainer, not even full time according to his résumé. What you just described is multiple specialists and some supporting tools, so another way of looking at this is to ask how much value the IT world has gotten from sudo but not contributed back in support.

When something is this widely used, it’s easy to forget that the answer to who should do more isn’t the one person who actually steps up to keep it alive.

There’s a number of reasons openbsd dropped it, and all of them are fundamentally rooted in size and complexity: https://flak.tedunangst.com/post/doas

For one, the config file is actually easy enough to read properly.

Having worked with the IC for decades, I'm well aware of what's going on.

Everyone has decided to stay home this year, though.

That is not fair. This software is maintained by Todd Miller, the well known OpenBSD developer, and has both tests and certainly discusses code proposals. Not everyone has to use github or the language de jour to be useful.

Ironic that OpenBSD dropped sudo in favor of a much simpler utility.

"C Is Not a Low-level Language, Your computer is not a fast PDP-11."

https://queue.acm.org/detail.cfm?id=3212479

In some point someone will rewrite all GNU/UNIX user land in modern Rust or similar and save the day. Until this happens these kind of incidents will happen yearly.

The problem is feature parity. Most rewrites cannot guarantee that off-the-bat, so they end up struggling to persuade people to switch - why break stuff that works just fine and lose features, in the name of some engineering purity?

https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/s...

Which also seems to not have tests. In fact, the only tests I'm seeing are from 2 years ago.

https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/t...

> has much better security

It's using D-bus. My faith in D-bus security is close to my faith in seeing a fresh Linux install with zero D-bus error messages from apps. Which is to say, nonexistent.

> integrates with your DE instead of expecting passwords on the terminal.

There's nothing inherently insecure about passwords on the terminal, and certainly nothing a DE can do better. I have yet to see a display manager or lock screen app that knows what the hell PAM is doing. Try doing even the simplest things with PAM, such as getting a fingerprint reader or Yubikey working, and every single display manager simply chokes.

I'm not sure which is more of a Byzantine mess: Linux authentication and authorization, or Linux audio.

With all the .so modules loading into some process, etc. Some questionable design in sshd makes it lock up completely for all incoming connections when used with PAM and when pam module ends up in infinite loop.

Nevermind that systemd pam modules pull in a shitton of stuff, including dbus, into any process that tries to use PAM for auth, these days.

I guess it all runs as root, too. sshd at least tries to fork a child for all this and waits for it and kills it, so that the parent process can't be polluted. It just has no timeout when waiting for result, and doesn't accept further connections when waiting.

Sometimes it's better not to look too deep under the covers.

sshd needs to run as root (obviously) because it grants login shells to people, so it needs to run in a privileged context. And the PAM modules it executes also need to be run as root, because PAM modules need to do things like read /etc/shadow.

(In the past, OpenBSD had a login-locally-or-via-Kerberos binary there, which does show the downside of that approach over PAM's more flexible approach.)

Implementing a subset of sudo is a weekend project, for some values of useful.

openbsd dropped sudo for "weekend project" `doas`, in no small part because it does not support most of that stuff.

Here's the configuration file documentation: https://man.openbsd.org/doas.conf.5

Not that I have any faith in modern "best practices". I'm imagining `grep` written in modern a modern language like JS and I shutter when I think of the hundreds of micro-dependencies like "left-pad" that would need to be downloaded to make it work.

Maybe it's fair to say that systems programming languages are in a better state in terms of modern best practices than scripting languages.

You don't have to imagine: `ripgrep` exists and has all of 10 direct dependencies, 4 of which by the same author because they extracted features / systems from ripgrep (or developed them separately from the start) as they were useful on their own e.g.

* regex, for obvious reasons

* ignore to match and apply ignorefiles (gitignore and friends which ripgrep takes in account by default)

* bstr for conventional utf8 strings rather than guaranteed

* grep intends to be essentially "ripgrep as a library"

Or everyone just switches to musl + busybox.

I'm not a fanboy for the sake of it, but you're being a little over your head here.

I don't mind expressing this opinion. There is nothing anywhere in the GNU project which should be emulated, except the license.

Unless it’s BSD, I guess?

[0] https://www.sudo.ws/history.html

And `ed` dates from 1969: https://en.wikipedia.org/wiki/Ed_(text_editor)

On the other side, I remember howtos/manuals/READMEs in the early '00s referring to su(1) and only sometimes saying "..these days you should be using sudo(8)", so it always felt like something "new" :)

The homepage for sudo is https://www.sudo.ws/

It is licensed under an ISC style license.