> Sudo is security theater.

Yes indeed.

> Malware can make a fake unprivileged sudo that sniffs your password.

Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su. So basically only root can use su and nobody else.

Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so login from tty2 ain't really an option) or by login in from another computer, using a Yubikey (no password login allowed). That other computer is on a dedicated LAN (a physical LAN, not a VLAN) that exists only for the purpose of allowing root to ssh in (yes, I do allow root to SSH in: but only with using U2F/Yubikey... I have to as it's the only real way to log in as root).

It is what it is and this being HN people are going to bitch that it's bad, insecure, inconvenient (people typically love convenience at the expense of security), etc. but I've been using basically that setup since years. When I need to really be root (which is really not often), I use a tiny laptop on my desk that serves as a poor admin's console (but over SSH and only with a Yubikey, so it'd be quite a feat to attack that).

Funnily enough last time I logged in as root (from the laptop) was to implement the workaround to blacklist all the modules for copy.fail/dirtyfrag.

That laptop doesn't even have any Wifi driver installed. No graphical interface. It's minimal. It's got a SSH client, a firewall (and so does the workstation) and that's basically it. As it's on a separate physical LAN, no other machine can see it on the network.

I did set that up just because I could. Turns out it's fully usable so I kept using it.

Now of course I've got servers, VMs, containers, etc. at home too (and on dedicated servers): that's another topic. But on my main workstation a sudo replacement function won't trick me.

You don't even really need that; you just need to wait until the user runs `sudo` and then you also run `sudo` after they authenticate. Now you're root, boom. It doesn't get you the password, but once you're root you can backdoor to your heart's content and then you probably don't need it.

Alternately, run `sudo --non-interactive --validate` over and over until it succeeds. For some reason, using noninteractive doesn't log to the auth log/journald the way trying and failing to actually run a command would.

Edit: the loop only works assuming you can run this sudo command in the background in the user's shell so that you can pick up the same sudo session when they auth, which is honestly unlikely. Easier to wrap sudo in a command that just also runs sudo and then immediately runs something else.

Use /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded.

Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.

Stupid thought.

Make alias called sdo that echoes sudo path and hash every time you use it to stderr.

That's security by obscurity though.

It would be great if

1. shells support the notion of privileged commands, that can't be overridden with PATH manipulations, aliases or functions.

2. Sudo (or PAM actually) can authenticate with your identity provider (like Entra ID) instead of a local password. Then there is nothing to sniff and you can also use 2FA or passkeys.

To clarify, when does this run? Like you download malware A, run malware A and this function definition changes sudo for it, or sudo for other cases?

sudo don't acccept password from stdin. it takes a tty

Just sudon't.

I had an idea to always run 2 users, the "main" one (or more) and a "project one"... one could sudo to the project user, but that one could not sudo out... (npm would only be installed for the project user).

Every user, since privesc is so easy on most operating systems.

Any application running as a user with sudo access and RW permissions on the users home folder effectively has root permissions, it'll just take a little longer to get it.

That's why Flatpaks sandbox doesn't exist if the application has access to the home folder.

And I'm increasingly concerned that one could vibe-code a massive payload that does all of these at once - including subtle things like trying to get itself installed into personal projects and forks, so it can persist across a system wipe. We're only seeing the beginning of these attacks.