1. There's value in sudo (or su, or ssh root@localhost, or whatever alternative you like to logging in directly as root) as a safety measure, which is different

1. There's value in sudo (or su, or ssh root@localhost, or whatever alternative you like to logging in directly as root) as a safety measure, which is different from a security measure. Not having a paper towel holder wall-mounted above your stove is a great idea to prevent accidental fires, but it's completely irrelevant to stopping an arsonist. It's worth distinguishing these two cases. 2. sudo can be used for both running a limited set of commands and for running an unrestricted set of commands. These are also two different cases. It's a bit tricky to ensure your limited set of commands are secure (you need to make sure none of the commands allow you to run unconstrained commands in turn), but if you do it, that is a meaningful security limit compared to giving a user account unrestricted sudo or running that code as root. This isn't usually relevant for typical desktop systems, but if you're looking at designing some more involved deployment, it's relevant. 3. For a multi-server deployment with a team of sysadmins, the question isn't really about sudo vs. su vs. ssh as root - the question is about the chain of accounts between a sysadmin's keyboard and their privileged shell. If you can come up with a design where the account that they can use (directly or indirectly) to log into root is more highly trusted than their everyday account (the one they use for downloading software from the web and trying it out, running code written by other people in the company, etc.), then there's a meaningful benefit. There's a lot of ways to do that. One is to allow them to log in from their workstation's account to both a privileged sysadmin account with sudo and an unprivileged everyday one, and they do their work logged in elsewhere with the unprivileged account. One is to allow them to log in from their workstation's account directly to root, or to an unprivileged everyday account - it's weaker in terms of auditing but it has the same security properties as the previous solution. One is to set up multiple local accounts on their workstation, one privileged and one not, so they can work locally with their unprivileged account. The important bit is that the unprivileged account can't escalate to the privileged one. It doesn't matter if it does so with sudo or with su or with ssh or whatever, all of those can be used to escalate privileges. If you really want, you can apply the scheme above to your desktop system. Make two accounts, have one be an admin account and one not. If you're installing drivers etc. switch to the admin account, but otherwise work in the non-admin account. If the non-admin account gets broken into, you can reliably use the admin account to wipe it and restore from a known-clean backup. That's generally annoying in practice, though.