sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.
I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team.
I asked for root access (via sudo) so I could do stuff like restart Apache.
The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands.
So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root.
I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it.
So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache.
When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it.
When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.
I know Apache supports being started as an unprivileged user (I do this myself a lot when I need something a little more featureful than SimpleHTTPServer) but my impression was that that's not very common for production deployments.
http://httpd.apache.org/docs/current/mod/mod_log_config.html...
More secure options would be to use CAP_NET_BIND_SERVICE instead of root, or to make Apache bind an unprivileged port and then use something like iptables (or an external load balancer) to redirect 80/443 to the privileged ports. But, for reasons I can't quite recall (it was 10+ years ago) we didn't take up any of those more secure options.
SSH public keys have the exact same feature however. Look at "command=" under "Authorized Keys File Format" in the man page. This is a good idea for batch jobs that uses SSH to execute on remote machines.
With SSH keys you even have the option of limiting keys not just to certain commands but to certain IP addresses. By limiting the SSH keys you also don't have to give your keys access to an unprivileged shell where you don't need it.
First, sudo should not be cached for this very reason. Second, agent caching should never be enabled for this very reason. Third, agent forwarding should never be enabled for this very reason.
Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable.
which most often is not the default on vps/root/clouds, that's basically my point. if you use sudo, use it with a password.
- attach to an existing screen session that has an existing process under sudo inside it
- edit .bashrc to alias sudo to something that records the password, then come back later
- spawn a background process that waits for the user to run sudo, then opens the pty and uses TIOCSTI to type commands at it
Also, if the attacker actually has control over the sysadmin's local machine, they can do a lot more damage, like any of the above locally, or
- send an email from the admin's account to the team saying "Hi, I'm trying to run this command but I left my RSA token at home, can anyone help?"
- add a browser extension that rewrites all <pre> tags to include a https://thejh.net/misc/website-terminal-copy-paste -style attack
- commit to code or configuration-management repos adding a back door and trigger a deployment
None of these are technically difficult attacks. Requiring a separate sudo password might slow down a script kiddie, but that's about it.