The thing is, sudo also tries to allow you to give much more limited access also. Such as run specific commands as another user without needing full root access. That does present a larger surface on the part of sudo, but it's a considerably tiny surface compared to giving the user full access with su and wheel.

We have an ever changing group of about 60 engineers who need the ability to do rooty style things on about 500 different machines (very few of which are the same, so things like ansible don't work too well). While only a handful actually do, the rest need to be able to, and they're trusted to make the call.

However we still want to know what's going on, and sudo fires back a message to syslog with who did it and what they did. Far more useful than "joebloggs went to root at 03:14 and logged out at 09:15"

If you take the time (once) to configure it correctly, auditd can tell you much, much more than just what commands were executed (and "hiding" the commands you ran via sudo is fairly trivial, if one is so inclined).

Wouldn't that simply say "root did this at this time", and maybe "on this pts", and then I'd have to marry that up with who was logged on at the given pts at that time?

Either way we don't sue sudo to enforce security -- anyone could go and reboot the machine physically in any case, we use sudo so we remember what we did, or can quickly find the person who did it. Same with physical security, we don't stop people from pulling the plug, but if the plug is pulled we can see who was probably in the room at the time. You can work around it (by going in with a colleague) if you wanted to hide your tracks, but people don't hide their tracks.

Of course the other benefit of sudo is to reduce the number of terminals logged in as root, where accidents can easilly happen.

Yeah, I started using OpenBSD's doas and it's surprising how many things expect sudo specifically.

For the most part, could you alias doas to sudo?

FWIW, I did exactly that on my OpenBSD machines when doas was first introduced and I can't think of any issues I've encountered.

Maybe? The one that sticks out in my memory is running sshuttle on Arch Linux; Arch considers sudo to be part of the base group, so it doesn't want to remove the package, and I think sshuttle invokes /usr/bin/sudo with special options to control it. But... I might try just making a sudo symlink in my path and see how it behaves; thanks for the idea:)

When all you have is a single user machine, and "gain root from my regular user" is all you want, su is enough.

Yes, sudo has a few more features, but just because you don't need them doesn't mean they are necessarily "unnecessary".

And if you look at the bug – that bug wouldn't have occurred in your setup. You could replicate the functionality where this bug occurs with sudo and pam, but I don't really think that's less "surface area", and I know the chance that I would muck up re-implementing sudo functionality that way with a greater chance than the sudo devs.

I use the same strategy on the multi-user shell machine I operate.

The few trusted admins are in the wheel group, there's no root logins over ssh, and there's no sudo. The regular users don't get to switch users and definitely don't get access to root even if they know the root password since they're not members of wheel.

Sudo has never seemed like a good idea to me, but I've never had the inclination to let some users do just some things as root. Most programs have ways to escape and get to a shell somehow, so relying on sudo to restrict access to specific programs is often fundamentally flawed because those programs themselves are more often than not incapable of restricting the user from escaping them with the elevated privs.