Slashdot Mirror
How Would You Distribute Root Access?
dhanks asks: "I'm one of 10 administrators in our group. We're equally responsible for about 300 UNIX servers. We're having problems keeping track of all the root passwords and some of the administrators have taken it upon themselves to implement different security standards. (sudo with silly !SHELLS restrictions) How do other companies and system administrators handle the distribution of root access? I've been charged with coming up with a security policy and I would like to receive some feedback. I'm currently thinking of personal root accounts that would be locked via the /etc/passwd and would only be accessible via 'sudo su - adm_userid' that way each administrator may have full root access only using his regular user password instead of having to keep track of root passwords." While this is similar to an earlier question, this question deals with insuring authorized administrators have the access they need. How would you distribute root over hundreds of Unix machines to the administrators that need it?
..I just made them a root-user which was typically nick-root, that way things could be more easily tracked, etc. Works pretty well.
I would expect such blatant racism on Fark, but on Slashdot? Mods please ban this asshole.
...and ssh rsa authentication in authorized_keys of root's. peice of piss.
I co-administrate a number of solaris machines and have created a bastion-host environment that forces all users to use the bastion and then work from there using a fake root account that uses sudo. The only password an admin needs is his own on the bastion host, sudo and ssh keys do the heavy lifting and everything gets logged. As an admin, I do not know the root password, and I like it that way.
Every action I take as root is logged through the sudo facitlity to a central logging server. Users who need role accounts and such log in through the bastion host and a number of sudo scripts log them in through ssh into the account. Its not a perfect system, but when admins leave, there is only one password to change and root is locked up in a cabinet on that odd chance that you need to do fsck (which the only time that I have found that I need the actual root password).
Q. What is Calvin's monster snowman called? A. The Torment Of Existence Weighed Against The Horror of Non Being
How Would You Distribute Root Access?
I wouldnt.
That is the point? isnt it ?
nick.
The wheel group is the traditional UNIX way of restricting root access to a privledged few.
/etc/suauth---it's in the man page.
It's not this way with GNU su, because RMS don't like it that way (too totalitarian, etc...).
You can make GNU su act like normal su by adding a line in
SDSC uses cfengine to enforce configuration policies. Their users do have root. (I've been looking for the ;login paper that discusses how exactly they do this. It's not on Google, so it must not exist. 8) Reimaging a system works as long as you can keep a root-enabled user from storing local data, or else you don't care about the consequences of losing any such data. It's also the correct last resort if things go badly wrong.
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
I administrate FreeBSD machines, and by default the wheel group decided who can and cannot run the "su" command at all, and that is with the root password. In order to su successfully, a wheel member must also have the root password; other users aren't allowed to even attempt it. I am sure that this can be changed to match the passwordless authentication that you have mentioned, but I actually prefer the current model I have been using. The security implications are complicated, but, password or no, if a person has root access, they can divulge the information no matter what. The biggest benefit to keeping the root password secret to all admins, however, is that they can't do direct logins as the root user; you will have good records of who did what from which admin's account.
Trying to "restrict" sudo access via ! commands is dumb - there are too many shell escapes, etc. At some point, you MUST trust your admins, so just give 'em sudo=ALL. Having said that, I would setup syslogging to a central loghosts, and have some sort of audit process so if someone does an "su root" or a "sudo csh" (or futzs with the syslog configuration), then you beat 'em over the head with a baseball bat! ;-)
Ohhhh ... you say can't do the later ... then you are basically screwed, since if you don't have management support for this, you'll never succeed unless all of your admins realize having logging/accountability/etc. of root-type actions is a darn good thing for everyone - those type of folks work hard to make SURE whatever they do is logged ... whereas there always seems to be at least one admin who thinks they are above this stuff - some eventually learn, some don't.
BTW, note the loghosts (plural) above ... you should have this allready in place for general security purposes ... and NO admin should have access to all of the loghost machines - i.e. this allows you to deal with renegade Sysadmins who cover try to cover their tracks ... or worse yet, someone who tries to "frame" another Sysadmin.
sudoscript was allready mentioned as a nice compliment to sudo, and the sudo tools are also handy for some auditing features.
Hulk SMASH Celiac Disease
We use powerbroker to control root and limited root access. Think of it as like sudo, but the rules are maintained on a centeralized, trusted host. The trusted host then authenticates and authorizes the request, then executes the requested command on the target host. And optionally loggs both the event (user x executed command y on host z), and can also record the entire session. .ssh/authorized_keys file with the "command=..." parameter (which forces that key into executing the specified script). That script can then take the rest of the command line, which specifies a target host / command / user, parse it, authenticate/authorized it, then issue the command on the target host using a seperate keypair (the public side of which is loaded in root's .ssh/authorized_keys file, and the private side is known only to the trusted host). You can have the trusted host authorize the command by matching it against your defined rules, using either a simple shell script or a perl script.
However, powerbroker is commercial software and a bit expensive. You can accomplish the same thing by having users run a script that issues an ssh command to a trusted server, which in turn relays that command (if approved) to the target host. The way you do this is to have one keypair that all client users use to issue ssh commands to the trusted host, and the trusted host then has the public side of that key in its
We have a little over 450 systems The eight of us can login to all of them via ssh to our regular unix accounts and su to root as needed. We all know the root passwords for all of the machines for use during emergency situations where direct console or single user mode access is needed. We also have a rather complex centralized sudoers file that doles out access to functional application groups to specific commands as needed. We've often discussed going to a model where we all have to use sudo to run commands as root, but in truth, it's never been a problem over the past 5 years. Sure people make mistakes, but that will happen no matter what. Anything that makes our job more difficult without adding any real value is a waste of time. Once you get into situations where you have hundreds or thousands of production systems, you'll be trying to do everything you can to weed out complexity, not add to it. If you have someone in your group running around like a cowboy and trying to cover their tracks, you've got more serious problems. These kind of things are better dealt with with peer pressure and the occasional beat down in the parking lot ... ;-)
"Who hasn't slipped into the break room for a quick nibble on a love Newton before?" - Mr. Peterman.
> "How would you distribute root over hundreds of Unix machines to the administrators that need it?"
/etc/ssh/authorized_keys/{login} using an access control list that we distribute to every box. The control file is centrally managed (kept in CVS) and has groupings for roles, individuals and servers, so administration is a breeze. The generator is just a short perl script. Finally, we have these lines in /etc/ssh/sshd_config:
/etc/ssh/authorized_keys/%u
:)
We have a similar team size and a similar number of servers. In addition there are other teams with access to more limited (regular user) team role logins. Access also varies according to server role and location.
These systems are often located in continents away in untrusted locations. So passwords are not acceptable.
My solution:
We have a standard Debian package that updates
AuthorizedKeysFile
PermitRootLogin without-password
We make a contingency for emergencies, but I won't describe it here. Suffice to say that it's safe enough to use, analysed enough that it's not snake-oil, and inconvenient enough to stop sysadmins in a hurry from using it by default
- J
I'm surprized that nobody mentioned cfengine2. I believe there are couple of ways you can distribute your passwords across the net using it... cfengine2 is an exellent solution to keep multiple computers intact..
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?