> Did you remove all of these?

So if you can't protect versus all the threats, you may as well not do anything?

Perhaps a more reasoned approach would be to rewrite them in rust, or some other hardened language for greater security.

What really matters is not whether you have sudo (or su, pkexec, etc.) installed, but rather that you never, ever escalate privileges from a less trustworthy user to a more privileged one, since at a conceptual level this combines the low trustworthiness with the high privileged-ness.

Instead, when you want to elevate privileges, you should do so by using a mechanism that takes the control of the machine away from less trustworthy user - such as a Secure Attention Key or similar mechanism.

But all of these programs escalate privileges from less trustworthy to more.

  $ ls -l /usr/bin/passwd
  -rwsr-xr-x. 1 root root 33424 Apr  1  2022 /usr/bin/passwd

The "s" above indicates that the program is allowed to call the setuid() family of functions to alter the real, effective, and/or saved user id.

You would not be able to change your password without the functionality.

Yeah, they do, but (in theory) they should either only allow you to do some very restricted commands (e.g. chsh, chpasswd), or require you to authenticate to run arbitrary commands (e.g. su, sudo).

The former are fine since they don’t allow arbitrary commands/escalation, and the latter (IMO) you should not use because it’s impossible to use them safely as you can’t trust the environment (the display server, terminal emulator, shell, etc.) to do what you say if it is compromised.

In practice, some of them will have bugs (and the kernel also has privilege escalation bugs frequently) so I don’t consider the user/root separation a particularly strong security boundary. For me it’s more of an additional layer against not very sophisticated attacks.

Yes, your position is more nuanced than I first surmised, not "never, ever."