[jeffbee]

All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested. The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change. The pull request that supposedly fixes this CVE also includes no tests. There is no reason anyone should believe this fix is effective or complete, or that it does not introduce new defects. This is the result of people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review, while at the same time using the industry's most dangerous high-level language. As long as this type of thing continues, our tools will remain at a very low level of safety, reliability, and correctness.

[gerdesj]

"All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested"

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.

[igneo676]

In short: There's nothing that you can do

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

[Sjonny]

> Fair enough but what do you recommend?

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.

[GoblinSlayer]

I want to start and stop a couple of systemd services remotely. Currently I expose the command with sudo and run it under a remotely connected user. What are other options?

[Spivak]

You don't actually have to be root at all to manage systemd services. If you give the user `org.freedesktop.systemd1.manage-units` in Polkit then they can just run systemctl as their user and it will work.

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

[ktpsns]

In your case either use plain /sbin/su: https://man7.org/linux/man-pages/man1/su.1.html or login via root. Your use case sounds very sudo-like, thought. Probably stick to sudo.

[GoblinSlayer]

It's a batch job. Ah, I see it mentions runuser, will check it.

[moistbar]

sudo doesn't have to grant full root access to everyone in the group. It can be set up such that certain users only have the ability to run specified commands as root, which is handy for orgs where you might have a group of tier 1 techs that you want to be able to run certain scripts (written by tier 2 or 3, of course) that require root, but you don't trust the engineers enough to have root access to everything.

[65a]

It is almost always the case that a sufficiently malicious user can find a way to turn that into full blown root access.

[moistbar]

So that means they should get full blown root from the beginning?

[Spivak]

IMHO yes because then you treat the access with the gravity that is required.

[lmm]

> Fair enough but what do you recommend?

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

[jart]

Use Actually Portable Executable which enables you to compile textbook C programs as unikernels that boot on bare metal, as well as execute natively on all the existing operating systems too (without needing a runtime or interpreter). We've been working hard to democratize ring0 privileges since spectre has made the performance costs of having an operating system too high: https://github.com/jart/cosmopolitan/issues/20#issuecomment-...

[lmm]

Much of the point of suggesting Mirage was to get away from C - my position is that the correctness costs of C's undefined behaviour (as implemented by real-world C compilers), limited testing support, poor dependency management and so on are too high.

[jart]

One of my goals with Cosmopolitan is to attract developers who build high-level languages. MirageOS depends on OCaml which depends on C. We need a sturdy foundation at the lowest levels that can enable these visions by helping high-level environments be successful. Cosmopolitan can be that foundation. For example, the codebase has 192 test programs. Much focus has been placed on using the Undefined Behavior Sanitizer and Address Sanitizer to vet everything. My past experience was working on projects like TensorFlow and I started security initiatives like Operation Rosehub which together helped us have the highest performance software infrastructure that's safer too.

[lmm]

> OCaml which depends on C

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

[pwdisswordfish6]

The libc is a runtime.

[jart]

By runtime I meant to say external runtimes. Your cosmo binaries are statically don't depend on anything except stable kernel interfaces, when you run on mac/nt/linux/bsd. That means it doesn't need to link any .so files like the glibc runtime. Therefore you won't be impacted by things like linux distro versioning and incompatibilities.

[danaris]

Does it have full support for all the kinds of stacks people are running on Linux today? Is there a robust ecosystem of MirageOS users online able to help troubleshoot issues from the simple to the arcane? Is it supported by VPS providers the world over?

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

[lmm]

> Does it have full support for all the kinds of stacks people are running on Linux today?

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.

[tbrownaw]

> The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change.

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

[saagarjha]

Tests you perform locally should probably be described, if not encoded into something that other people can run as well.

[TomSwirly]

"You can't prove no one tested that!" is not really a good basis for robust software design.

[jonhohle]

In addition to the value of repeatability, it’s just being a good human to show and share your work.

[iovrthoughtthis]

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

[cheph]

For some code you should be able to do this, and if you can't then I don't think you should be writing code.

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.

[kaba0]

For some code, yes. What about a complete refactor of the core functionality of said program, with parallelism and the like?

[cheph]

I misread the comment I think, but either way, I am not arguing against automated tests, I was just trying to point out that for some fragments of a code base you should absolutely be able to tell correctness by looking at it.

[muricula]

Even if there were basic unit & regression tests, this bug might not have been caught. This bug should have gone through detailed security review and should probably also undergo fuzzing.

[jeffbee]

You can bet your bottom banana that the GRU, the NSA, Chinese state security, and the mob have all thoroughly fuzzed sudo and are sitting on the results.

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.

[mike_d]

It sounds like you'd find great pleasure in writing harnesses for oss-fuzz. Google has found and reported over 25,000 bugs in 375 projects, but they need people like you to help wire up new projects.

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

[arp242]

Maybe expecting projects that mostly consist of a single guy working on it in their spare time to be "NSA proof" isn't really realistic?

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.

[Someone]

No, you can’t. I think the blame shouldn’t be on this author, but on those choosing to install it or, worse, choosing to ship it on their OS.

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.

[greggyb]

Sudo was (maybe still is?) an OpenBSD project. I don't believe it originated there, but their code forms/formed the basis for sudo pretty much everywhere, much like OpenSSH.

[JoachimS]

doas is a a really good replacement.

[pocketgrok]

Maybe something that’s sole purpose is privilege escalation, like sudo, should come with some expectation of responsibility.

[jolux]

No, but having tests is an acceptable baseline.

[arp242]

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

[jolux]

The thing is, "do what thou wilt" is clearly indefensible as an engineering standard, and I doubt you would disagree. So yes, I can't force anyone to write tests.

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.

[brigandish]

People can do what they want in their spare time, true, but that it is their spare time does not make the action responsible or irresponsible, nor does it shelter them from responsibility.

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.

[jjoonathan]

> It just seems SO EASY

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

[natevancouver]

Does the project have a testing framework in place? How is the project built and distributed? Can testing be integrated into its CI/CD pipeline? Is there a CI/CD pipeline? Adding frameworks and infrastructure to a project is one of those things that is a lot more work than it appears to be. They should do it, for sure, but I wouldn’t dismiss it as trivial on a decades-old system that was never built for it.

[bnroberts]

Single persons often have superhuman standards. It is easy to see that most of the best works in math or art were produced by an individual.

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.

[jeffbee]

31 CVEs later I think it's safe to say that this particular author does not possess superhuman standards. How much more evidence would we need?

[acdha]

We’d all like that, true, but look here:

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.

[jart]

Wow he changed two million lines of the sudo codebase over the project history and made 10,548 commits. That's bonkers. Sudo is clearly doing a lot more under the hood than I thought it did. A simple security critical command shouldn't have that much churn. It should arc towards immutability like TeX, which has had like twelve changes in the last 40 years.

[masklinn]

> Sudo is clearly doing a lot more under the hood than I thought it did.

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

[jart]

OpenBSD is a fabulous project. I've been working on tool called Cosmopolitan which helps Mac/Linux/Windows/FreeBSD developers write software that's compatible with OpenBSD: https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... As you can see, I've studied these systems a lot and I've got to say that OpenBSD is the closest to the Bell Labs roots I've seen from community distros. It takes a certain degree of judiciousness to maintain that authenticity and the clairvoyance w.r.t sudo should be all the proof we need that OpenBSD is up to something good.

[breakingcups]

Sidebar: Wonderful post, but what an awful fake loading bar. Every time I switch from the tab / window to something else and switch back to continue reading I'm interrupted by it for no reason.

[gerikson]

You're supposed to disable javascript in your browser.

[kazen44]

doas is a wonderful alternative to sudo.

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

[anonymousiam]

Does he moonlight for the NSA?

[acdha]

This response is the “must be aliens” of security. If you remotely think this is the case, ask whether one of the top intelligence agencies in the world would be more likely to attract attention to a deep cover operation many, many years in the making or would invest in making sure that the bug was well concealed so nobody else would be able to use it on, say, .gov servers. If you remember Dual EC_DRBG I know which one I’d bet on…

[anonymousiam]

It was meant as a joke. Lighten up.

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

[acdha]

I figured it was a joke but it's about as original as a standup routine complaining about airline food.

[gnunez]

A Turing Award winner once said, “Program testing can be used to show the presence of bugs, but never to show their absence!"

[jeffbee]

Sounds like a very smart person. Much of the value in the test is showing that the old revision fails it. If I were fixing this bug, first thing I would do is write the test and make sure the existing code fails. If it doesn't fail, that means I don't understand the problem yet. Then I fix the problem and commit both the fix and the test. I don't just discard the test, because it is valuable to know that in the future nobody re-introduces the exact same flaw (this regularly happens in open source projects).

[gnunez]

I agree. Keeping the test around provides a safety net (a bug repellent of sorts) for the next person the comes along. The test also serves as a documented history of the bugs of the past. The problem is that test does not guarantee the injection of future bugs of a different type. I don't think any amount of testing will. That's not to say we shouldn't write test, we should just be aware of the limits of testing.

[jrockway]

A journey of a thousand releases begins with the first unit test.

Everyone has decided to stay home this year, though.

[xorcist]

> people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review

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.

[srfilipek]

> This software is maintained by Todd Miller, the well known OpenBSD developer

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

[nsajko]

I think the design of the relevant code is worse than the lack of relevant test coverage. The problem solved insecurely by the code instead seems like an obvious target for lexical and syntactic analysis (and this has been so since the sixties, I think).

[megous]

Yes, please at least use re2c when parsing anything more complicated in C. The result is much more readable, and integration costs are pretty low, and you still keep a lot of flexibility in how you structure your code.

[pfundstein]

Did you just call C a high level language?

[pjmlp]

Indeed,

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

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

[pocketgrok]

Technically, it is. But usage of the term has shifted a lot over the last 50 years.

[beams]

Stopped reading your comment after the first sentence because that’s all I needed to know.

[miohtama]

Another question is who wants to maintain four decades old GNU C soup? It was written at a different time, with different best practices.

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.

[im3w1l]

Rewriting sudo is a weekend project*. Getting people to adopt it is a many-year political campaign.

[toyg]

You can bet your last dollar that if the "right" RedHat or Debian developer rewrote sudo with feature parity, it would be adopted by all major distros in a couple of months. It's the sort of thing nobody really cares about except OpenBSD (which wrote their own).

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?

[axaxs]

Poettering to save the day with systemd-sudo?

[kuschku]

Polkit-exec (pkexec) already exists, has much better security, and integrates with your DE instead of expecting passwords on the terminal.

[deckard1]

This thing?

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.

[vbezhenar]

Does it work without GUI?

[magicalhippo]

https://www.youtube.com/watch?v=TkR9QWuoyJ8

[rogerbinns]

That would indeed be a huge feat of programming skill! I refer you to the configuration file documentation to treat as a spec: https://www.sudo.ws/man/1.8.3/sudoers.man.html

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

[jeffbee]

That's part of the dark outcome of so many untested features: it makes it easy to cast FUD upon any potential replacements. As we have no black-box test suite that shows `sudo` implements all of these features, so we also cannot have faith that any replacement would. Ideally it should be possible to run sudo's black box tests against any potential replacement. To start with, we need those tests.

[arp242]

There are actually a bunch of tests for the sudoers file format.

[masklinn]

> 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

[stouset]

This is why OpenBSD has `doas`.

[umvi]

> It was written at a different time, with different best practices.

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.

[acdha]

Try https://github.com/BurntSushi/ripgrep – it’s across the board better, and one of the best personal productivity boosts you can make if you use grep frequently.

[masklinn]

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

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"

[megous]

I actually like some modern grep alternatives, like `ag`.

[young_unixer]

> someone will rewrite all GNU/UNIX user land in modern Rust or similar

Or everyone just switches to musl + busybox.

[anthk]

Or doas. Much simpler.