[kelnos]

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff.

It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if there's a bug in it, an unauthorized user might be able to use it for privilege escalation. If that's really the main issue, then you can:

    chgrp wheel /usr/bin/sudo
    chmod o-rwx /usr/bin/sudo

Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. This essentially gives you the same access-related security as the sshd approach (the UNIX socket there is set up to be only accessible to users in wheel), with much much much less complexity.

And since the sshd approach doesn't allow you to restrict root access to only certain commands (like sudo does), even if there is a bug in sudo that allows a user to bypass the command restrictions, that still gives no more access than the sshd approach.

If you are worried about your system package manager messing up the permissions on /usr/bin/sudo, you can put something in cron to fix them up that runs every hour or whatever you're comfortable with. Or you can uninstall sudo entirely, and manually install it from source to some other location. Then you have to maintain and upgrade it, manually, of course, unfortunately.

[tankenmate]

Personally I use etckeeper[0] to make sure all changes to /etc are tracked, either by software installs / upgrades, or done by humans. It's also great when needing to upgrade a machine to a newer release as you can create a patch file with all your local changes and apply that patch to a clean install and do a three way merge that will highlight all conflicts and keep you up to date and any changes required from one release to the next without having to research everything just in case.

[0] https://etckeeper.branchable.com/

[spydum]

such a great idea, i have not seen this before. back in my solaris admin days, we used to keep config stuff version controlled locally like this with rcs; found it super useful for quickly answering "what changed, and how" during incidents (whereas just looking for modified files and fetching backups was a slow ordeal)

[kstrauser]

I like Chezmoi for this, and also use it to manage my home directory.

Plain ol’ git is also nice in a pinch.

[mschuster91]

Honestly I prefer running Ansible for that. Once you have a boilerplate set up the overhead is minimal and you don't have to fight each specific program's config file syntax just to figure out how to do comments.

[alexey-salmin]

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them.

That's very sensible, I wonder why it's not the default setup everywhere.

[kelnos]

Probably because there's nothing that says only users in wheel (assuming your OS/distro even has that group; some don't) can sudo. You can grant any user with any group membership access to sudo, either full access, or restricted to only certain commands.

If the package was set up to install /usr/bin/sudo so it was only runnable by members of the wheel group, that wouldn't work.

[kmeisthax]

It's worth noting that the reason why your OS/distro doesn't have or doesn't respect wheel is largely down to RMS opposing it[0], instead favoring people trading the root password around to unauthorized users.

[0] https://web.archive.org/web/20070603191229/http://www.gnu.or...

[sham1]

It's also worth noting that the Coreutils `su` is no longer in use by anyone, and that the `su` from the shadow-package absolutely checks for wheel. It's even configurable if you haven't enabled PAM by configuring `SU_WHEEL_ONLY` in your login.defs. And with PAM you configure that via PAM.

Hell, not even GNU distros like GNU Guix, Parabola, nor Trisquel follow RMS' opinions on this anymore.

[ilius2]

Not all distros use `alias su='sudo -i'`. Ubuntu does. Debian does not. Not sure about others.

[dingensundso]

Having a wheel group that is allowed to run any command with su rights is the default setup, but it's not the only one.

I have used sudo a lot of times to allow a specific user to run exactly one command with elevated rights. In those cases they weren't in the wheel group.

[riedel]

Actually retristricting defined commands to defined sudoers should be one of the main use cases of sudo. This could be done as well via ssh config but one would need a lot of keys if you don not want a wrapper (and rewrite sudo all over)

If you are really thinking security, elevating a standard user seems bad practice to anyways. It is rather I guess a way to protect the user to do `rm -rf /` accidentally. On the other end adding an another layer of obscurity is practically adding a bit of security against script kiddies. But if that is of concern one could also rename the sudo binary.

One last thing the SSH trick might be interesting is the portability but in this case I would rather go via a standard TCP socket.

[jkhanlar]

Has anyone prepared a list of distributions indicating the default sudo setup comparing to each other? I'd be interested to see the defaults for each distro as a factor to consider.

[cqqxo4zV46cp]

It’s at the very least incompatible with *some^ hypothetical sudo configurations. It’s probably a good hardening practice if you know how sudo is going to set up on the machine.

[peanut-walrus]

Not every user who uses sudo is admin or elevates to root.

[rascul]

I've seen a wheel or sudo group often enough to think it's common.

[euroderf]

Pardon my ignorance, but I have to ask for explanation of what the wheel group is and does. I'm aware that this might open a can of worms.

[kqr]

In addition to being the default name for the admin group in Debian, the name has some history:

> [from slang ‘big wheel’ for a powerful person] A person who has an active wheel bit. “We need to find a wheel to unwedge the hung tape drives.” The traditional name of security group zero in BSD (to which the major system-internal users like root belong) is ‘wheel’.

> The term was invented on the TENEX operating system, and carried over to TOPS-20, XEROX-IFS, and others. The state of being in a privileged logon is sometimes called wheel mode. This term entered the Unix culture from TWENEX in the mid-1980s and has been gaining popularity there (esp. at university sites).

http://www.catb.org/~esr/jargon/html/W/wheel.html

[WD-42]

Great bit of history, thanks!

[ffsm8]

The wheel group is just a regular user group, its just the name Debian gives the group with admin permissions.

It's no different to any other user group on linux systems and you could replace the name wheel with admin, freethinker, systemdestroyer or whatever else you wanna call it.

[bozey07]

Not really! In modern Linux specifically it's just a regular user group, but it's the de-facto standard name of the "administrator" group - users who can escalate to root privileges.

You might not even have wheel anymore; Debian just calls it "sudo" now.

[lttlrck]

Maybe also make /usr/bin/sudo immutable? would that help prevent a package manager from messing with it? I think so.

[kelnos]

The downside of this is that if you have your system set up to automatically install package updates, then it will start failing, which might kill all automatic updates.

On Debian, for example, I have unattended-upgrades set up to automatically install security updates. sudo is reasonably likely to have updates for security reasons.

[dpifke]

There are multiple ways to "override" a file managed by dpkg:

https://wiki.debian.org/DebianAlternatives

https://www.debian.org/doc/debian-policy/ap-pkg-diversions.h...

[ec109685]

How would you do that?

[vrotaru]

lsattr - for reading attributes chattr - for setting them

You need the `i` attribute. But this is filesystem dependent. Anyway protecting the `sudo` binary from package managers is a so-so idea.

[xomodo]

man chattr

[blueflow]

> And since the sshd approach doesn't allow you to restrict root access to only certain commands [...]

The ForcedCommand infrastructure.

[flakes]

There's also a command argument that can be provided in the authorized keys setup, which can force connections with a particular key to hit an entry-point application.

[blueflow]

This is the ForcedCommand mechanism.

[bandie91]

note, that even with ForcedCommand, sshd still executes ~/.ssh/rc in the user's name, so she can execute arbitrary command once she can write the rc file (unless disabled by PermitUserRC).

shameless plug: you can prevent this by https://github.com/bAndie91/tools/tree/master/ssh-groupcomma...

[vbezhenar]

If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole.

Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.

[arp242]

> IMO. suid feature is huge security hole.

As opposed to running background processes as root...?

This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.

[herczegzsolt]

The argument is, that in case of sudo, the caller (potential attacker) controls the environment. In many cases, software or libraries are not made with a hostile environment in mind. Think of LD_PRELOAD or PATH ...

When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control.

Libraries rarely treat data from socket as "trusted" but often blindly trust environment variables, or stdin/stdout/stderr.

[arp242]

That has nothing to do with setuid, and is a very different argument from an unqualified "suid feature is huge security hole."

sudo etc. already clear much of the environment. And you're going to want to keep some of it because people expect "sudo foo" to work (which you can't do without PATH).

[westurner]

"List of Unix binaries that can be used to bypass local security restrictions" (2023) https://news.ycombinator.com/item?id=36637980

"Fedora 40 Plans To Unify /usr/bin and /usr/sbin" (2024) https://news.ycombinator.com/item?id=38757975 ; a find expression to locate files with the setuid and setgid bits, setcap,

man run0: https://www.freedesktop.org/software/systemd/man/devel/run0....

[guerby]

Except when physically logged in via console you're already using ssh before using sudo.

So the complexity you describe is already there.

sudo removed is one less moving part in the end.

[inopinatus]

That is a furphy, because both tools are also used non-interactively.

If you forced me to choose one to remove, I’d delete ssh in many cases. Anything production that isn’t bare-metal is a candidate for never allowing a remote terminal. Easiest with cloud instances since they’re almost completely disposable, but many sites still don’t have the stomach/discipline for it.

[krispyfi]

TIL: "furphy" https://en.m.wikipedia.org/wiki/Furphy

[kelnos]

I don't see how two sshd daemons and two sessions is less complicated.

Yes, removing sudo is one fewer moving part, but sshd is a much larger moving part than sudo. (If you think sudo is a larger moving part than it should be, I'd agree, and you can use doas instead.)

Regardless, the vast majority of my sudo usage is on my local machine, so there's no sshd involved at all.