Hacker News Reader

Comment by randomblock1 | Hacker News Reader

This is trivial to fix, at least for you.

  %corestaff ALL=NOPASSWD: /usr/bin/mailq "", \
                           /usr/sbin/exim -bp, \
                           /usr/sbin/exim -bpa, \
                           /usr/sbin/exim -bpc, \
                           /usr/sbin/exim -bpr, \
                           /usr/sbin/exim -bpu

That being said there definitely should be an automated way to check for incompatibilities between normal and rust sudo.

View on HN

Before you know it, you will be needing a workaround for every replacement tool you use in Ubuntu. This is what makes it unacceptable.

> This is trivial to fix, at least for you.

Or one could just install (real) sudo instead of (fake) sudo.

Installing real sudo is something I will have to do when (if) we move to 26.04 because we need LDAP functionality, and fake sudo does not provide that.

forgive me if i’m wrong. i don’t think you’ve ever had to administer more than a handful of machines. your “fix” is irrelevant.

> That being said there definitely should be an automated way to check for incompatibilities between normal and rust sudo.

yes. it’s called the bare minimum.

If you're using `sudo` for something beyond trivial `reboot`, you're doing something VERY wrong.

Like.... apt-get?

So you want users to be able to install any package? So that the attack surface is now literally all the Debian archive?

Yeah, no.

You either use `sudo` when you want full root access or for something completely trivial.

My sudoers is set up to let me run update and upgrade (with no args) without a challenge, but not install.

I'm pretty sure I can b0rk the system by interrupting the upgrade in an inconsistent state. Or maybe inject some fun environment variables into the `apt-get` context. And I think you can launch the shell during conflict resolution for conffiles, giving you instant full access to the whole system?

A more robust design is to have a systemd one-shot unit that users can activate (via a trigger file or sudo).

So my point still stands and your example illustrates it perfectly. Either you use `sudo` for full root access or for something entirely trivial.

`sudo apt install my-custom-backdoor-script.deb`

With NOPASSWD you would also invite someone pulling a `.deb` via `curl` as part of a supply chain attack in a some non-descript NPM package via a git hook or something.

If you're not in the user community of a tool, having an opinion on whether or not the replacement should work doesn't seem like it should matter to you at all.

The complexity of tools and the associated danger absolutely matters.

What are you doing wrong?

I do manage more than a handful of machines, and that means using automation tools and IaC as much as possible, while avoiding humans using shells as much as possible. I’m struggling to enumerate a lot of use cases for a bespoke sudo configuration that shouldn’t be a proper setup.

Reply on news.ycombinator.com