[tbrownaw]

> Despite this, the wisdom of the crowd is that you should never su to root, for ... reasons?

`su` takes the password of the user you're becoming, while `sudo` takes the password (or not) of the user you already are. So using `su` to become root implies that there's a root password that multiple people (well, assuming there's multiple admins on the box) know.

[tgbugs]

I firmly agree that sharing passwords is bad, however I can't imagine a threat model where password sharing among multiple parties is more risky than giving multiple people sudo. As zests points out, practically there is no difference because anyone with sudo can change the root password, they are already root, so the auditing use cases is moot if the logging system can't distinguish between two users sudo sued into root at the same time.

Having multiple admins that need to be able to administrate a system might seem like another case where sudo simplifies things, but isn't that what the wheel group is for? Yes there is an M:N issue between administrators and root passwords and we all know that reusing root passwords across boxes is just asking to get pwnd, but if admins can already ssh into a user that has wheel on a system then that implies that there is another existing authentication system that surely could be used to provide the password in a centralized manner. There is complexity in such a service, but that is only required for the M:N case and if it has issues then it can be fixed once. Busted sudo? You have to push emergency updates to (checks notes) ... literally every EC2 image on amazon. If admin:server is 1:N then password manager, copy, paste, and cut sudo out of the loop entirely.

[tbrownaw]

> I can't imagine a threat model where password sharing among multiple parties is more risky than giving multiple people sudo

An individual leaves the company and the security / compliance people say all their access to be revoked, which is kind of a headache with shared logins.

The security / compliance people want audit logs of who does what, which is harder to do with shared logins.

I think both of these things are encouraged (maybe required?) by various certifications that companies doing certain things might need.

[zaarn]

sudo can be restricted to specific commands, so you can restrict non-root users to do VERY specific actions (ie, the webdev can reload apache2 but not restart or stop it or take any other action).

This means the webdev has the least amount of access necessary for their work without giving them straight up root or using setuid on a script, which can lead to easy bugs (did you check PATH?)

[kortex]

There are huge differences between running with user as sudo and running as root itself. Much more of an audit trail with sudo. You can trace which account ran which command. Sure you can cover your tracks with sudo but it's far harder than with bare root, even more so with shared accounts.

[nsajko]

If a system is configured as you describe, that just means that it then effectively has an additional root/admin account, except under a possibly unpredictable name. So security through obscurity, really (if the privileged user name is secret). That might make sense for some small number of setups, but instead it seems to be enormously popular, and often times it is even used in the security-defeating manner of having the "usual" user be privileged.

[zests]

sudo su

My favorite command.

[koprulusector]

This is so silly that it's absolutely ludicrous, but I've never known about or used that before....... I can think of all kinds of other permutations of the command that I've used and know but not this one......