I find this thread very very interesting. I'm one of the 10 SysAdmins that dhanks works with. Yes, I have servers with quote the silly sudo with !SHELL endquote restrictions.
First a bit of background - these are AIX servers, sudo is set up so sysadmins can't just go to a shell (plus a few other minor restrictions), there are normal password settings (8 characters, etc), modest logging is enabled, and there are Corporate Security Policies and Practices. Only the Primary and Secondary SysAdmins know the root password (plus the Supervisor in a sealed envelope). All other 8 SysAdmins are supposed to use sudo. Oh, and somewhere we've acquired 150 servers that I know nothing about....
I've been gradually putting these things in place due to Sarbanes-Oxley and the increasing security needs in our world. DHanks has been affected by this since he likes to use a common dictionary word for his password, and he absolutely does not want anyone else to be able to see what he does on a server.
Now to tie it back to the various parts of this thread - I too used to trust all our SysAdmins until one showed me how wrong that was. Take a look at the following.sh_history file from the dhanks directory (sorry for the length):
/usr/local/bin/sudo vi rm.sh rm.ksh cd/ grep root/etc/passwd ( cd/home/root ls -lt.ksh ls -lt.sh_history tail.sh_history "sleep 10; >/home/root/.sh_history &";exit cd/home/root ls tail.sh_history ls -lt.sh_history/usr/local/bin/sudo tail/home/root/.sh_history/usr/local/bin/sudo Rsh telnet exit exit/usr/local/bin/sudo cd/usr ls *sh cd bin ls *sh/usr/local/bin/sudo/bin/tsh/usr/local/bin/sudo/bin/msh/usr/local/bin/sudo/bin/chsh/usr/local/bin/sudo/bin/bsh bash exit exit sudo/bin/ksh set -o vi/usr/local/bin/sudo/bin/ksh/usr/local/bin/sudo cp/bin/ksh/tmp/fuck-this/usr/local/bin/sudo/tmp/fuck-this passwd otheruser sudo rm/tmp/fuck-this set -o vi/usr/local/bin/sudo rm/tmp/fuck-this/usr/local/bin/sudo cp/bin/ksh/tmp/shell/usr/local/bin/sudo/tmp/shell whoami vi/etc/security/limits cd/etc/security ls grep doug * vi user exit exit
I'll let this speak for itself, though any comments are welcome on what you see. In other history files, there is evidence of editing of various system log files, and other non-condoned work. For a while the history file was piped to/dev/null.
I believe this clearly points out that sudo and almost any other technique I've seen discussed in this whole thread is only effective if the SysAdmin is trustworthy to start with. Once any kind of root level access is achieved, there are too many ways for someone to get around logging, sudo resctrictions, etc. Possibly at higher auditing levels, this is harder, but still not impossible.
If you read the original question, the last italized sentence, you'll see that the security policy is designed to give full root access to all SysAdmins. Is this wise where you have SysAdmins willing to do what you see in the history file?
Slashdot Mirror
Well the history file got a bit butchered (some lines were combined), but you can see what was going on....
I find this thread very very interesting. I'm one of the 10 SysAdmins that dhanks works with. Yes, I have servers with quote the silly sudo with !SHELL endquote restrictions.
.sh_history file from the dhanks directory (sorry for the length):
/usr/local/bin/sudo vi .sh .ksh / /etc/passwd /home/root .ksh .sh_history .sh_history /home/root .sh_history .sh_history /usr/local/bin/sudo tail /home/root/.sh_history /usr/local/bin/sudo Rsh /usr/local/bin/sudo /usr /usr/local/bin/sudo /bin/tsh /usr/local/bin/sudo /bin/msh /usr/local/bin/sudo /bin/chsh /usr/local/bin/sudo /bin/bsh /bin/ksh /usr/local/bin/sudo /bin/ksh /usr/local/bin/sudo cp /bin/ksh /tmp/fuck-this /usr/local/bin/sudo /tmp/fuck-this /tmp/fuck-this /usr/local/bin/sudo rm /tmp/fuck-this /usr/local/bin/sudo cp /bin/ksh /tmp/shell /usr/local/bin/sudo /tmp/shell /etc/security/limits /etc/security
/dev/null.
First a bit of background - these are AIX servers, sudo is set up so sysadmins can't just go to a shell (plus a few other minor restrictions), there are normal password settings (8 characters, etc), modest logging is enabled, and there are Corporate Security Policies and Practices. Only the Primary and Secondary SysAdmins know the root password (plus the Supervisor in a sealed envelope). All other 8 SysAdmins are supposed to use sudo. Oh, and somewhere we've acquired 150 servers that I know nothing about....
I've been gradually putting these things in place due to Sarbanes-Oxley and the increasing security needs in our world. DHanks has been affected by this since he likes to use a common dictionary word for his password, and he absolutely does not want anyone else to be able to see what he does on a server.
Now to tie it back to the various parts of this thread - I too used to trust all our SysAdmins until one showed me how wrong that was. Take a look at the following
rm
rm
cd
grep root
( cd
ls -lt
ls -lt
tail
"sleep 10; >/home/root/.sh_history &";exit
cd
ls
tail
ls -lt
telnet
exit
exit
cd
ls *sh
cd bin
ls *sh
bash
exit
exit
sudo
set -o vi
passwd otheruser
sudo rm
set -o vi
whoami
vi
cd
ls
grep doug *
vi user
exit
exit
I'll let this speak for itself, though any comments are welcome on what you see. In other history files, there is evidence of editing of various system log files, and other non-condoned work. For a while the history file was piped to
I believe this clearly points out that sudo and almost any other technique I've seen discussed in this whole thread is only effective if the SysAdmin is trustworthy to start with. Once any kind of root level access is achieved, there are too many ways for someone to get around logging, sudo resctrictions, etc. Possibly at higher auditing levels, this is harder, but still not impossible.
If you read the original question, the last italized sentence, you'll see that the security policy is designed to give full root access to all SysAdmins. Is this wise where you have SysAdmins willing to do what you see in the history file?