How Would You Distribute Root Access? 148
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 would combine them. (Score:5, Funny)
Second, create one giant supercomputer cluster from the 300 machines.
Third, give your new super administrator root access (with their choice of password) on the new supercomputer.
Re:I would combine them. (Score:2)
My second question would be is who would win Voltron or any one of the Power Ranger Ripoffs?
My third question is can I use that supercluster to boost my folding@home scores???
Re:I would combine them. (Score:2)
maybe I'm just special.
In times past.... (Score:4, Informative)
Re:In times past.... (Score:2)
That would be the reason why Nick was fired after the last time the system went down...
Re:In times past.... (Score:3, Funny)
Daniel
use cpp and sudo (Score:1, Interesting)
You can even use sudo's built-in mechanism between differentiating hosts.
You will get very fine-grained control, as different people will have different access through just running the preprocessor.
Sudo and CVS (Score:5, Interesting)
As for the CVS side of things, I just keep a "sysconf" module for each server. Whenever I make any changes to a system file, I will first add it into CVS. Then all subsequent changes are made to the CVS version'd file, and notes and stuff committed to CVS. After committing to CVS, the admin then moves the file into the proper system location and does whatever else is neccessary to make the changes take effect. Once again, it doesn't work unless people use it. There's nothing I have in place that would keep someone from editing the file in the system location (since they need root to put the file into place...), but I try to discourage people from doing that.
Eventually I'd like to write some scripts and a DB backend that will hold the locations of all the files, so it's easier to move them into the proper location. But I haven't started that yet...
Re:Sudo and CVS (Score:4, Funny)
Re:Sudo and CVS (Score:2)
Re:Sudo and CVS (Score:2)
Re:Sudo and CVS (Score:3, Interesting)
Re:Sudo and CVS (Score:3, Interesting)
Re:Sudo and CVS (Score:2)
Re:Sudo and CVS (Score:5, Insightful)
If you do not trust a user, then do not make them a trusted user. Leastaways don't make them a trusted user on the machine that is supposedly logging their actions.
Re:Sudo and CVS (Score:2)
That's pretty much what I was getting at... despite whatever sort of measures you put in place w/sudo or whatever, you still have to trust the people that you give root access
Re:Sudo and CVS (Score:2)
then put all your nasty stuff in there. Then
from inside vim. The right answer is the one that oneiros27 pointed out [slashdot.org]: semi-trusted users should only get access to a very select few executables via the sudoers file.
The logging answer is close to what you say: log keystrokes, and don't do it on a machine that they have access to. Like o1d5ch001 pointed out [slashdot.org]. Both of their posts get at the issue with simply firing some
"sudo bash" (Score:2)
It's been increasing used as a form of alternative for root -- there is no root password, and a user must come in through their own account, and sudo commands.
I'm personally okay with that, as if the person is 'root', they can do any damned thing they want on the box. If you don't want them to do things, don't give them root. If you
Re:Sudo and CVS (Score:3, Informative)
Every action I take as root is logged through the sudo facitlity to a central logging server. Users who need
Re:Sudo and CVS (Score:3, Insightful)
I'd therefore recommend you change the actual root password when anyone who had sudo access leaves.
Re:Sudo and CVS (Score:2)
Use the tools you have.
Public Keys, ACLs, and sudo (Score:5, Insightful)
Re:Public Keys, ACLs, and sudo (Score:2)
Also, I'd pick Subversion (or even CVS) over RCS, since you can create a central server to store all configuration information for every machine. This is extremely nice when you want to clon
What about key-based SSH authentication? (Score:5, Insightful)
So nobody would get in touch with actual root passwords, which can be stored at a safe place.
iButton? (Score:2)
Anyone ever played with ibuttons or similar items for this purpose?
Re:What about key-based SSH authentication? (Score:3, Insightful)
Of course even one hour's root access is enough to enable the user to add their own back doors (e.g. other user accounts). So you'd also need to monitor things like /etc/passwd and shadow file changes carefully. And tools like Chkrootkit [securiteam.com] can help.
But definitely, ssh public/private key authentication is the way to go.
- Linux VPS Hosting [rimuhosting.com]
Kerberos (Score:4, Interesting)
In practice, Kerberos is really hard to do right and so far ssh support is very weak. But if everything was kerberized (this is in the works), then everything from logins to web access can go through your ticket. Granting root privileges is merely a matter of setting the acl properly and then letting the use ksudo.
Re:Kerberos (Score:2)
I'd use PAM (Score:2, Insightful)
"su" accounts (Score:5, Interesting)
In general, nobody should EVER type the root password, only their su$NAME password. That way, if it gets compromised (accidentally typed somewhere bad) you only have to change it in one place (NIS master) rather than on all machines.
All of this seems pretty obvious, so let me know if there's something unusual about your setup that makes this unworkable.
Re:"su" accounts (Score:2)
Out of curiosity, does that play nice with sendmail? I'm trying to decide whether that's really cool because it allows mail sent to Menscher to reach me just as my normal menscher account would, or if it would suck because mail to menscher would maybe be hijacked by Menscher and dumped into /var/mail/root.
Re:"su" accounts (Score:2)
Have you actually tried this? With which MTA?
Re:"su" accounts (Score:2)
(It's really difficult to know whether to be happy that my post got modded up, or pissed off that it was modded funny.)
One Word. (Score:5, Interesting)
Novell Directory Service.
Oops, that's three words. Try "eDirectory" instead.
No, wait a second - I seem to recall that Novell marketing renamed it yet again - now it's called either Ngage, exteNd, Nsure, or Nterprise - not sure which.
Frankly, I'm not even sure the people at Novell know what it's called anymore.
Maybe we should moderate Redmond "+1 Has a Clue" simply for fielding a marketing team that knows its ass from a hole in the ground...
Re:One Word. (Score:2)
extend is somewhere beteween a Web Portal product, a Web library... General webyness. It (can) heavily use(s) eDir.
nsure is one "usefull" layer on top of eDir. Apps to define workflow, policies, etc etc. eDir is the database, nsure is the middleware. High level stuff using eDir as the backend.
nterprise is (another) "usefull" layer on eDir. Or a collection of usefull layers. Look
Re:One Word. (Score:2)
When you're not the dominant player, not many are going to bother sifting through all the marketing bullshit and crap to figure out what your product actually is and does.
Anyone remember HP's espeak?
Re:One Word. (Score:2)
Except that they're ideas... (Score:2)
Novell Directory Services is an implementation of these sorts of ideas which has about a 15 year track record [used to be called 'NetWare Naming Services' back in the NetWare 3.x days], and for easily the last ten of those years, it's been a stable, rock-solid, enterprise platform in mission-critical environments [not to mention the fact that it's withstood pretty much every attempt to crack it].
Now you could certainly roll your own home-brew implementation of Kerberos & LDAP
Re:Except that they're ideas... (Score:2)
Little basic info about Netware 2/3 -- user and group data (as well as printers, etc) were stored in a database called the bindery. Each server had a binary, and there was no way to join multiple servers to a single administrative domain. Netware 4, with NDS, replaced the binary with an x.500 derivative.
Now that you've got the history, you might be wonder h
Re:I think we're in agreement here... (Score:2)
But again, they're just ideas... (Score:2)
What I was basically getting at was the fact LDAP and/or Kerberos were the technologies that would overcome his problems, regardless of who the vendor of said technologies are.
But again, "LDAP and/or Kerberos" are just ideas. Microsoft has an implementation of these ideas, called "Active Directory." Sun has an older implementation of these ideas, called "Yellow Pages," and a newer implementation, called "iPlanet." A now defunct company, called "Banyon," had an implementation of these ideas, called "Vines
Normal User Accounts... (Score:4, Informative)
Doesn't solve all problems. (Score:2)
I want a red swingline stapler, dammit, so I get fired.
Clever me, I long ago used my ssh key to become root, then I copied all the other admin's private keys onto my flash USB keychain fob (Root superusers can do that sort of thing, y'know. We have powers beyond the ken of mere mortals).
So, after I am forcibly ejected from the building, I just ssh back in as some other administrator.
And then, override the door locks, fire alarms, and sprinkler system so I can BURN TH
blah (Score:5, Funny)
Re:blah (Score:2)
Personally, I use 12345. It's on my luggage too!
Re:blah (Score:2)
Auditing.. (Score:4, Insightful)
Depending on what operating system you are using, you could turn on execve / set*id auditing. This functionality is available in a variety of unix implementations (BSM for Solaris, Snare for Linux,
Alternatively, many OSs provide 'sulog' or equivalent.
Note though, that auditing root suers is an inherently risky process, as a root user can cover their tracks quite easily by removing audit log data; as such, you might want to consider real-time forwarding of audit data to a central server, getting it off the host machine, and away from the administrative influence of the root-level user. For basic log files, this is effectively a tail -f | send across the network. For OS-level auditing, it's generally a little more complex.
Red.
Comment removed (Score:4, Funny)
Re:"How Would You Distribute Root Access?" (Score:2)
Audit Trail? sudo+sudoscript (Score:3, Interesting)
dealing with this as well... (Score:5, Interesting)
Give _everyone_ root access. These machines are behind a firewall, right? These are used by developers working to design/forward your company's projects right? If there's the slightest chance that they'll need root, give it to them.
Now, how do you deal with the chaos that results?
Simple. Write a script that reimages the drives on a regular basis. Daily, weekly, monthly, or even by command. In that way, you know the machines will always be kept up to date.
Use your existing admins to maintain and develope the image that you push down to the client machines. Every user should know that the machines will be reimaged often and that they can't plan on the machine always being in the same state. If they have an application or library that they want to persist, then have a procedure for having one of your admins add it to the master image.
User files should be kept on a file server elsewhere. Home directories may or may not be mounted to the machines as you like.
Everyone deserves root. Even those people that are going to screw the system up. (Once or twice, and they won't do it again.)
Re:dealing with this as well... (Score:4, Insightful)
What! You've got to be kidding me! Unless you're also requiring them to also fully administer their machines, this is one of the lamest ideas I've seen in months.
Just because they're developers doesn't mean they're smart, competent or even computer savvy. It certainly doesn't mean that they're trustworthy.
Re:dealing with this as well... (Score:4, Interesting)
Look, this knocks out a bunch of issues all at once:
1. Keeps all machines up to date with the latest everything (so long as you keep your master copy up to date).
2. Frees up power users from having to hunt down a sysop when they want to do something unique.
3. Keeps machines cruft free - if they're rebuilt, they're clean.
4. You still have admins and master configurations, so non-power users won't even know the difference. They probably won't even know they have root!
Open your mind a little. Did you trash your machine when you got root? Probably. Probably once or twice. But in so doing, you also learned how the machine worked.
Give them a sandbox to play in and they'll build castles.
Re:dealing with this as well... (Score:3, Interesting)
I like the idea of empowering users. I agree that giving them root will
Re:dealing with this as well... (Score:2, Funny)
Idiotic (Score:2)
The most idiotic suggestion on Slashdot!?!?
That sounds like a poll idea, or an ask slashdot. But I don't think this comes anywhere near qualifying. Still, it does make me want to go rummage around a bit to see what might qualify.
Re:dealing with this as well... (Score:3, Informative)
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 d
Re:dealing with this as well... (Score:2)
That's why you're a user and they won't give you root.
Try vmware (Score:2)
Then everyone gets their own machine or ten, or however many they want that fits into say the 120GB drive you give them. 40GB for main PC stuff, rest of 80GB: if 5GB per virtual machine = 16 virtual machines..
If they screw up or whatever, they can either rollback from a snapshot they've saved or they can just get a copy from various pristine vmware images you make available on a network share - e.g. Win2Kpro-SP4, Win2Kpro-SP3, WinXP-nopatc
Re:dealing with this as well... (Score:2)
One thing I've done that seems to w
Re:dealing with this as well... (Score:2)
long long ago (Score:2)
just had personal UID0 accounts for each person holding root. That way if you have to remove someone's root access, you just rmuser on them, and it's done.
their convention was to use each person's first initial of either their first or last name + (oot).. so they had root, zoot, woot, loot, toot, etc...
The "wheel" group (Score:2)
Just a thought.
Re:The "wheel" group (Score:4, Informative)
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
Re:The "wheel" group (Score:2)
Re:The "wheel" group (Score:2)
http://www.catb.org/~esr/jargon/html/W/wheel.html
Re:The "wheel" group (Score:2)
Pity they didn't use the phrase "Billy Big Bollocks", and the group name "billybollocks".
Re:The "wheel" group (Score:2)
Re:The "wheel" group (Score:2)
In which case, one has to wonder how he can support the concept of multiuser at all...
Re:The "wheel" group (Score:2)
Re:The "wheel" group (Score:3, Informative)
Re:The "wheel" group (Score:2)
it is possible to make it so that if they are a member of the wheel group to explicitly "trust" the user when they type 'su'.... {so they can become superuser without knowing the specific root password)
Re:The "wheel" group (Score:2)
Yeah, put wheel in sudoers. However the man page for sudoers is a masterpeice of lengthy, ineffective documentation.
Heres what I do (Score:3, Interesting)
ssh private keys (Score:2, Interesting)
Disable the root password (or set it to something nobody knows), and only allow access via ssh's public/private key system. If you have a script which will set up the
This way nobody has to remember a password(s), you don't have to worry about cycling passwords, and
Re:ssh private keys (Score:3, Insightful)
Re:ssh private keys (Score:2)
I don't know if they've improved in recent years, and I don't care. 8)
well...to be honest... (Score:2)
give each server a root password, make each of the 10 admins change it one 30 machines once a month on a schedule and anyone who decides that they want to use their own "additional" security policy (shell shenanigans, etc) gets locked out until they learn to play nicely.
I'm not a big fan of sudo, and while it does have it's uses, I don't think sudo should be used on a production server (not to mention that the admin who knows how to properly maintain a sudoers file is a rare thing indeed.)
Re:well...to be honest... (Score:2)
I don't know what they do about root passwords, beyond the fact that they are not disabled, but I'd take a similar approach to them. I'd change them on a schedule through automation, and check that they work nightly or more often.
(They don't give the root password to consultants, but I do have sudo most everywhere. Go
rdist sudoers (Score:5, Interesting)
When I worked at UnixOps [colorado.edu] we had several different versions of
Michael. [michael-forman.com]
Re:rdist sudoers (Score:2)
The analogy holds for positive and negative reasons.
GNU/Linux is affordable. MacOS is expensive. GNU/Linux is utilitarian. MacOS is luxurious.
At home I have a GNU/Linux server and two Apple laptops. At work I have a GNU/Linux server, an Apple G5, and a Sun Blade 2000.
If you're a GNU/Linux troll, who got their feelings hurt, you can relax. It's all Unix.
Michael. [michael-forman.com]
You're still using "root"? (Score:5, Interesting)
If you use "root", someday you will be rooted.
Ideas (Score:2)
I'm experimenting with SE Linux so that access can be controlled. In effect, you distribute only the privileges that each person needs, none of them are root. I'm not an expert on this approach, but it looks very promising. I'd love to hear from people with real-world experience.
Three little letters (Score:2)
NIS!
How-to presentation of using sudo at large site (Score:4, Informative)
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 [komar.org] are also handy for some auditing features.
Re:How-to presentation of using sudo at large site (Score:2)
FreeBSD's filesystem has an "immutable" flag. If you set that flag on a file or directory, and set the system's securelevel to a suitably high value, then that file cannot be tampered with except by rebooting the machine. If Linux has a similar facility, that's a nice way to make it impossible for someone to "futz with the syslog configuration".
low-tech solution (Score:2, Interesting)
The basic idea is to use a locked box to store the passwords in. The box is secured with a simple padlock, to which every knows the combination. For each machine you want to manage the password for, you have an envelope in the box with that machine's name on it in the box, along with a bunch of empty envelopes and some blank password sheets which I'll describe later.
So, you're setting
Powerbroker (Score:3, Informative)
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
How bad are they? (Score:2, Informative)
Beyond SSH (Score:3, Informative)
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
Re:Beyond SSH (Score:2)
If your contingency plan is so perfect, why are you afraid to describe it publicly?
gpg/pgp file (Score:2)
cfengine2 (Score:2, Informative)
This question may not be what it seems (Score:2, Informative)
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
Perhaps I don't get the problem, but... (Score:2)
I recommend a similar technique to friends and relatives who have no clue how to pick "good" passwords - pick a nice, random seven-char password, and make one consista
Re:Perhaps I don't get the problem, but... (Score:2)
with several (many) administrators, getting them the latest password for 300 (different root password) machines is fraught with potential for compromise - printed e-mail, unencrypted e-mail, etc.
not having the admin on the spot with the right password at the right time due to some administrative screw-up
The point is that either the admins are trustworthy, or they should not be admins. The problem is not one of access, but rather one of accountab
Re:Perhaps I don't get the problem, but... (Score:2)
May I suggest that if you can remember a random 7 character string with another algorithm to insert another character better than your dog's name or your chil
ssh and personal responsibility (Score:2)
So... don't piss them off - but in case you do (or they're truly evil)
don't allow root logins (by "normal" means such as tty, rsh, etc.) - only on the physical console (done via settings in /etc/ssh/sshd_config) - and then restrict access to the machine room (yes, really - don't even let the CEO in unless s/he signs the book)
create a master .ssh/authorized_keys file and a distribution list - and test
Re:How Would You Distribute Root Access? (Score:2, Funny)
[user@machine:~]$ fakeroot /etc/shadow
[root@machine:~]$ whoami
root
[root@machine:~]$ rm
rm: remove write-protected regular file `/etc/shadow'? y
rm: cannot remove `/etc/shadow': Permission denied
Problem solved, right?
Re:Easy (Score:2, Funny)
Just for an educational survey
Can you give me the ip of one of those boxes that is on the net?