From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability.
I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.
I don't find 'sudo' to be complex at all. If in your situation I would have had the ability to log in as root, in my situation I will be in the 'wheel' group. It seems very straightforward to me.
I think you misunderstand my point. You have increased the complexity of securing the system. You now have each user's login shells, all of the joys of what those login shells touch, the sudo program and its configuration, all added to the attack surface.
For accountability the openssh server already logs the key fingerprint.
The main security implications of sudo are a false sense of security and the risks related to having a password on your account and typing it in all the time (how often have you spilled it into a bash history?).
Sudo can't provide a dependable audit trail because it is trivially circumvented ('sudo bash'). It doesn't protect you from local-to-root exploits either.
It doesn't even protect you from yourself but rather makes your critical commands more complicated and error prone (shell globbing/escaping, pipes and redirects, etc.).
What is the false sense of security created by sudo? You don't have to have a password on your account to use it. You can use NOPASSWD or you can use pam_ssh_agent_auth to verify ssh keys if you are very paranoid. (Users still should not log into the servers with passwords.)
sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just fix the logs? To fix this, you must use snoopy to log commands to syslog, then syslog to a different computer. This makes both 'sudo' and root's ssh keys as accountable as one could ask for, I think. (As I could ask for, anyway.)
It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo." If you are running as your own user, it's much harder for a stray 'rm' to bring down the system. You might clobber your own files, but then you just restore from your backup.
What is the false sense of security created by sudo? You don't have to have a password on your account to use it.
You seem to think sudo adds security even when you don't use a sudo password. That's precisely the false sense it creates.
snoopy
On vanilla Linux there is no dependable audit trail after someone becomes root, period.
that you are meant to think about what you type if it begins with "sudo."
Because you don't think when you type into a root shell?
The mythical "stray rm" is a strawman. I've never heard of one happening in the real world. If you're that careless then sudo won't save you either.
What I do see often is people spending minutes on trial & error because sudo turns even trivial commands into a minefield when a pipe/redirect, the shell environment, globbing or a loop gets involved.
sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just fix the logs? To fix this, you must use snoopy to log commands to syslog, then syslog to a different computer.
Wait, you just said "neither does anything else", and then gave an example of how to create an audit trail. ;-)
In truth, you should use auditd or similar systems to really have a proper audit trail.
You're absolutely right that sudo doesn't make an audit trail more worse. It just doesn't make it any better either. It does, however, create a bunch more ways that someone can hack your system.
It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo."
How about you write a shell script on your own system, call it "sudo", and have it do "ssh root@admin.system $*"? You see what I mean? Maybe you are used to using sudo, but there is no reason the "oh noes, now I need to be careful mode" has to be a privilege escalation command on the host your are administrating. In fact, it shouldn't be. It really should be before you have logged in.
Comments
1. Disable root
This doesn't add any security, it only makes your admin life miserable.
I keep trying to explain to people that if anything this adds complexity to the security problem...
Can you explain this to me?
We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.
From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability.
I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.
I don't find 'sudo' to be complex at all. If in your situation I would have had the ability to log in as root, in my situation I will be in the 'wheel' group. It seems very straightforward to me.
I think you misunderstand my point. You have increased the complexity of securing the system. You now have each user's login shells, all of the joys of what those login shells touch, the sudo program and its configuration, all added to the attack surface.
For accountability the openssh server already logs the key fingerprint.
The main security implications of sudo are a false sense of security and the risks related to having a password on your account and typing it in all the time (how often have you spilled it into a bash history?).
Sudo can't provide a dependable audit trail because it is trivially circumvented ('sudo bash'). It doesn't protect you from local-to-root exploits either.
It doesn't even protect you from yourself but rather makes your critical commands more complicated and error prone (shell globbing/escaping, pipes and redirects, etc.).
Fair enough (wrt accountability).
What is the false sense of security created by sudo? You don't have to have a password on your account to use it. You can use NOPASSWD or you can use pam_ssh_agent_auth to verify ssh keys if you are very paranoid. (Users still should not log into the servers with passwords.)
sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just fix the logs? To fix this, you must use snoopy to log commands to syslog, then syslog to a different computer. This makes both 'sudo' and root's ssh keys as accountable as one could ask for, I think. (As I could ask for, anyway.)
It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo." If you are running as your own user, it's much harder for a stray 'rm' to bring down the system. You might clobber your own files, but then you just restore from your backup.
What is the false sense of security created by sudo? You don't have to have a password on your account to use it.
You seem to think sudo adds security even when you don't use a sudo password. That's precisely the false sense it creates.
snoopy
On vanilla Linux there is no dependable audit trail after someone becomes root, period.
that you are meant to think about what you type if it begins with "sudo."
Because you don't think when you type into a root shell?
The mythical "stray rm" is a strawman. I've never heard of one happening in the real world. If you're that careless then sudo won't save you either.
What I do see often is people spending minutes on trial & error because sudo turns even trivial commands into a minefield when a pipe/redirect, the shell environment, globbing or a loop gets involved.
Wait, you just said "neither does anything else", and then gave an example of how to create an audit trail. ;-)
In truth, you should use auditd or similar systems to really have a proper audit trail.
You're absolutely right that sudo doesn't make an audit trail more worse. It just doesn't make it any better either. It does, however, create a bunch more ways that someone can hack your system.
How about you write a shell script on your own system, call it "sudo", and have it do "ssh root@admin.system $*"? You see what I mean? Maybe you are used to using sudo, but there is no reason the "oh noes, now I need to be careful mode" has to be a privilege escalation command on the host your are administrating. In fact, it shouldn't be. It really should be before you have logged in.