Hacker News new | ask | show | jobs
by tgbugs 1967 days ago
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.

3 comments

> 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.

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?)

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.