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
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
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
> "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