Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems Software Unix

How Would You Distribute Root Access? 148

Posted by Cliff from the elevated-privileges dept.
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?
This discussion has been archived. No new comments can be posted.

How Would You Distribute Root Access? More

How Would You Distribute Root Access?

Comments Filter:

  • I would combine them. (Score:5, Funny)

    by Anonymous Coward on Wednesday May 12, 2004 @06:27PM (#9133258)
    First, create one super administrator from the 10 (sorta like Voltron).

    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.
    • My question is how many geeks here are old enough to know Voltron?
      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???

  • In times past.... (Score:4, Informative)

    by revmoo ( 652952 ) <slashdot.meep@ws> on Wednesday May 12, 2004 @06:27PM (#9133264) Homepage Journal
    ..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 just made them a root-user which was typically nick-root

      That would be the reason why Nick was fired after the last time the system went down... ... but seriously... if the have root access, can't they create themselves additional root accounts, tamper with system logs, etc?
    • That's far too complex! The obvious solution is to give all the boxes the same root password, kept in a central location (such as on a postit note at the entrance of the server room).

      Daniel

  • use cpp and sudo (Score:1, Interesting)

    by Anonymous Coward
    You should have one big global sudoers file which is able to get preprocessed by cpp or m4. Then simply output the preprocessed file on a per-server basis.
    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)

    by JofCoRe ( 315438 ) on Wednesday May 12, 2004 @06:31PM (#9133304) Journal
    I keep track of system changes on our linux servers using sudo and CVS. Admittedly, my situation is on a much smaller scale (2 admins, handful of systems). I like to use sudo because then any command that's run as root is traceable back to who did it via the system logs. (of course someone could hide their tracks by editing the logs...) I trust the other admin here, but in the past, I've set up sudo so that people could NOT USE the su command. The reason I did this is so that someone couldn't do a sudo su -, and then do whatever they want as root, unlogged. There are still workarounds, as sudo is not a be-all-end-all of security. You still need standard procedures, and you have to make sure people follow them.

    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)

      by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Wednesday May 12, 2004 @06:54PM (#9133605) Journal
      The reason I did this is so that someone couldn't do a sudo su -, and then do whatever they want as root, unlogged. There are still workarounds, as sudo is not a be-all-end-all of security. You still need standard procedures, and you have to make sure people follow them.
      sudo bash
      C'mon, man. That's not exactly a "workaround."
      • Good call. Another one is 'sudo vim', where a quick :sh command will drop you into a root shell.
      • You can patch bash/tcsh to log all actions to syslog. It can be quite useful as a supplement to sudo's logs.

        • Re:Sudo and CVS (Score:3, Interesting)

          by innosent ( 618233 )
          Expanding on this idea, why not patch bash to log all actions by users with uid 0, then create an account for each admin with uid 0. On some OSs, this may also require a kernel patch to hold the username as well as the uid, since I know that Linux used to store only the uid, and uses that to lookup the username (which will then resolve to the first matching entry), and do not know if this is still the case. If possible, you could also consider using and admin group (like wheel), but this may not be enough

          • Re:Sudo and CVS (Score:3, Interesting)

            by mwa ( 26272 )
            That's close to what I did. The patch makes a static bash run setuid 0 and logs via syslog everything they enter exactly as if they where running with set -x. (It used to log the output as well, but it makes for very messy logs if you trap screen oriented stuff like vi sessions, etc. Knowing who editted a file and when has been sufficient for isolating blame^W accountability.) It also requires the userids, from and to, be defined in a secure file (chmod 0, owned root:root). It logs what user called it, and
            • I have a root-level user (uid 0) for each of my admins. Works ok. Could be better. I've also written a simple wrapper around our CLI text editors like vi (bleah!), joe (ewww), and pico (don't laugh!) to stuff the changes into RCS with a copy of $LOGNAME and a timestamp as comments. It works pretty well. That way I can tell which admin ran chmod -R 720 .* from their personal home directory (grrrrrrr).

        • Re:Sudo and CVS (Score:5, Insightful)

          by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Wednesday May 12, 2004 @11:14PM (#9135595) Journal
          Ok, ok. You convinced me. A workaround is needed:
          sudo wget http://ftp.gnu.org/gnu/bash/bash-2.05b.tar.gz
          sud o tar zxf bash-2.05b.tar.gz
          cd bash-2.05b
          sudo configure;make;./bash
          Here's a hint: If you are a trusted user, then you can create a process that will do all the things you desire without logging. You could patch the OS and log system calls, but they could patch the OS and fix your logs.

          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.
          • 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.

            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 :)
      • Sudo is intended to grant access to specific programs to users. Typically, it's used when there is a specific set of tasks that a user, or group of user may need to perform.

        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)

      by o1d5ch001 ( 648087 )
      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

      • Re:Sudo and CVS (Score:3, Insightful)

        by phaze3000 ( 204500 )
        Except that with sudo access anyone with sudo access could easily get hold of /etc/shadow and then crack the root password. Create a shell script with an innocuous sounding name which grabs /etc/shadow, run it via sudo - all you're going to see is the user with sudo access has run a script.

        I'd therefore recommend you change the actual root password when anyone who had sudo access leaves.

    • http://www.infrastructures.org/
      Use the tools you have.

  • Public Keys, ACLs, and sudo (Score:5, Insightful)

    by imsmith ( 239784 ) on Wednesday May 12, 2004 @06:31PM (#9133316)
    With that many systems, the only rational access control seems to be to be using public keys and SSH agent to deal with the logon issue. Once in the system, the only way to keep track of so many cooks in the kitchen is to have sudo running and logging sysadmin actions. Finally, if there are specific files or groups of files that need special attention, I'd probably use ACLs to control access. Another thing that seems like a pain in the ass until it saves you is RCS. Especially with so many admins, being able to roll back a config change quickly is a lifesaver.
    • I fully agree, except that I think this is a strong case for SSH with Kerberos authentication. If you fire a sysadmin, the last thing you want to have to do is to de-authorize them from several hundred machines where they have root access. A centralized authentication system could provide a big payoff in this setup.

      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)

    by DocSnyder ( 10755 ) on Wednesday May 12, 2004 @06:33PM (#9133334)
    Every admin can generate his SSH key pair and have the public key appended to /root/.ssh/authorized_keys. Maybe the private keys could be stored on a USB stick or a chip card for better security. They should be protected by key-specific passwords, too.

    So nobody would get in touch with actual root passwords, which can be stored at a safe place.

    • Quite some time ago, a slashdotted mentioned this [ibutton.com] as having worked for him. I've yet to actually starting playing with mine (though I do have one), but I plan to basically have an apps which scans for the presence of a button (maybe upon a certain key being held) and grants access if the unique ID on the ibutton matches the one in records.

      Anyone ever played with ibuttons or similar items for this purpose?

  • Kerberos (Score:4, Interesting)

    by caseih ( 160668 ) on Wednesday May 12, 2004 @06:34PM (#9133340)
    In a perfect world, Kerberos is the way to go. Your kerberos ticket would, according to the access controls on each box, grant login and root privileges. SSH can pass along your ticket, granting you seamless access with your credentials.

    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.

  • I'd use PAM (Score:2, Insightful)

    by Anonymous Coward
    PAM, Pluggable-Authentication Modules. The PAM Radius module, with a central radius server, has worked for me in my testing, but I wish the module was a little more featureful in doing something with return attributes. It's one of those things I kept wanted to do, never had time for. A random descriptive page I found is here [samba.org] One minor caveat: it's moderately easy to misconfigure PAM to allow too much access - just be careful and use a standardized configuration.

  • "su" accounts (Score:5, Interesting)

    by menscher ( 597856 ) <menscher+slashdot@u i u c . e du> on Wednesday May 12, 2004 @06:36PM (#9133373) Homepage Journal
    You imply that all admins have root on all machines, and that all machines are clustered in some way. If that is the case, you might already be using YP/NIS to distribute passwords. So just give each superuser an UID0 account on your NIS master (our convention is su$NAME), and that will be distributed. If you want to limit some of their access to certain machines that can be done....

    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.

  • One Word. (Score:5, Interesting)

    by mosel-saar-ruwer ( 732341 ) on Wednesday May 12, 2004 @06:45PM (#9133484)

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

    • Ngage is Novell Corps consulting, training, support wing. Obviously, Novell will consult, provide training and support for eDir.
      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
      • Heh, maybe Novell needs you to help them explain things.

        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?

  • Normal User Accounts... (Score:4, Informative)

    by fozzmeister ( 160968 ) on Wednesday May 12, 2004 @06:48PM (#9133521) Homepage
    ...and ssh rsa authentication in authorized_keys of root's. peice of piss.
    • See, it's like this...

      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)

    by byolinux ( 535260 ) on Wednesday May 12, 2004 @06:51PM (#9133566) Journal
    just all use the password 'secret' - nobody would ever think a root user could so dumb.

  • Auditing.. (Score:4, Insightful)

    by RedPhoenix ( 124662 ) on Wednesday May 12, 2004 @07:00PM (#9133673)
    You may want to consider establishing a basic auditing policy, to back up any access controls you put in place.

    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, /dev/audit for AIX, Irix, Unicos, etc.).

    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)

    by account_deleted ( 4530225 ) on Wednesday May 12, 2004 @07:16PM (#9133811)
    Comment removed based on user account deletion

  • Audit Trail? sudo+sudoscript (Score:3, Interesting)

    by hbo ( 62590 ) * on Wednesday May 12, 2004 @07:25PM (#9133884) Homepage
    sudoscript [egbok.com] preserves your audit trail in root shells. It's not perfect, (there are still ways to evade the auditing) but if your concern is to have a record of root's actions so that problem diagnoses is easier, rather than keeping malicious users from doing bad stuff, then it's useful.

  • dealing with this as well... (Score:5, Interesting)

    by orn ( 34773 ) on Wednesday May 12, 2004 @07:29PM (#9133933)
    I'm a user dealing with this right now. Here's what I wish they'd implement at my place.

    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)

      by Brandybuck ( 704397 ) on Wednesday May 12, 2004 @07:42PM (#9134052) Homepage Journal
      Give _everyone_ root access.

      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)

        by orn ( 34773 ) on Wednesday May 12, 2004 @08:53PM (#9134634)
        I'm not saying that the users are trustworthy. That's why you have a cron script reimage the drive regularly. It's not a last resort, it happens always.

        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.

        • Varations on this theme have been tried in varying environments with varying degrees of success. So called "thin clients" can acheive a result similar to reimaging a "fat" client on a daily basis. But unless you have bandwidth to burn, downloading the system images from central servers won't scale to thousands of seats very well. Satellite servers could ease this problem, but then you have a more complex, and thus more fragile system.

          I like the idea of empowering users. I agree that giving them root will

    • Re:dealing with this as well... (Score:2, Funny)

      by Anonymous Coward
      This could possibly be the most idiotic suggestion I have ever heard on Slashdot.

      • Idiotic (Score:2)

        by jefu ( 53450 )
        Wow!

        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.

    • It's not so idiotic. There are several approaches that allow everyone to have root. My sudoscript tool was written to fit into just such an environment. The audit trail was designed to allow the IT department (me) to figure out what went wrong when someone shot themselves in the foot. (See The Problem of PORCMOLSULB [egbok.com] for more on my experiences with this.)

      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


    • That's why you're a user and they won't give you root.
    • If it's x86 stuff maybe you should try vmware or something similar.

      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
    • The problem I have in my environment is that some developers want root access on the main fileserver -- where we keep user home dirs and the mainline source. There are occasions when they want to change ownership on files or directories, and they're not able to do so unless they're root (or sudo'ing chown). When someone messes up a root command there...well, there's hell to pay for them and me. It's happened more than once and sometimes the abuser simply never learns.

      One thing I've done that seems to w

  • a bbs a long time ago, one machine.. but lots of roots.. (had tons and tons of users)

    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...
  • Don't know if this would help in your situation, but a while ago on a LUG list I heard about the "wheel" group. Don't recall the exact details, but apparently some *nix systems allow a set-up where ordinary users who belong to the "wheel" group can "su" without a root password.

    Just a thought.

    • Re:The "wheel" group (Score:4, Informative)

      by bersl2 ( 689221 ) on Wednesday May 12, 2004 @07:59PM (#9134204) Journal
      The wheel group is the traditional UNIX way of restricting root access to a privledged few.

      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 /etc/suauth---it's in the man page.
      • Do you know why its called "wheel"?
        • ... Because only people who are "Big Wheels" have that access. While I get the joke, its not much of one at all. OTOH, I also get "UNIX". UNIX: the OS based on not very funny jokes.

          http://www.catb.org/~esr/jargon/html/W/wheel.html

      • It's not this way with GNU su, because RMS don't like it that way (too totalitarian, etc...).

        In which case, one has to wonder how he can support the concept of multiuser at all...

        • Straight from the su texinfo page:

          Why GNU `su' does not support the `wheel' group

          (This section is by Richard Stallman.)

          Sometimes a few of the users try to hold total power over all the
          rest. For example, in 1984, a few users at the MIT AI lab decided to
          seize power by changing the operator password on the Twenex system and
          keeping it secret from everyone else. (I was able to thwart this coup
          and give power back to the users by patching the kernel, but I wouldn't
          know how to do that in Unix.)

          Howe

    • Re:The "wheel" group (Score:3, Informative)

      by vga_init ( 589198 )
      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
      • if using PAM on a redhat/fedora compatible system (could be any PAM aware system);

        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)

  • Heres what I do (Score:3, Interesting)

    by Sogol ( 43574 ) on Wednesday May 12, 2004 @07:56PM (#9134175) Journal
    This may not work for you depending on your situation:

    1. Make sure that only root can execute the su command.
    2. Distribute access to the su command via sudo, and only allow specific syntax for loading roots .profile
    3. In roots profile, establish a separate history file for each original user, and a log which shows where they are connected from, and whatever else you need separated by human user
    The drawback is that most users cannot su to a non root account, but they can still ssh user@localhost. This is by no means a particularly robust solution, but it is better than having the root account shared completely IMHO

  • ssh private keys (Score:2, Interesting)

    by Fred Nerk ( 128328 ) *
    I find the best way to distribute root access is not to use passwords at all.

    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 .ssh/authorized_keys file automatically, then removing someone's access or granting access to someone is a simple matter of running the script across all the systems.

    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)

      by hbo ( 62590 ) *
      The problem with this is single-user mode. Even though there are various tricks to get console root on various flavors of Unix, in a large organization, you can bet that a sysadmin that doesn't know the particular trick for the OS in consideration will have to go in to single-user to fix something. The consequences of this could range from annoying (3:30 AM: "Hi, Mr Senior Sysadmin Guy. How do you get root on xyz?") to fairly painful, like having a revenue-critical database server down 45 minutes longer tha
      • Fortunately, I haven't been near an SGI in six years. Great hardware, atrocious software. And a lack of understanding about how real servers are administered, as your experience shows.

        I don't know if they've improved in recent years, and I don't care. 8)
  • I wouldn't.

    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.)
    • At the Very Large Company I'm currently working at, they distribute sudoers nightly to thousands of hosts. Most sysadmins have no reason to be skilled at writing sudoers rules as a result.

      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)

    by Michael.Forman ( 169981 ) * on Wednesday May 12, 2004 @08:16PM (#9134337) Homepage Journal

    When I worked at UnixOps [colorado.edu] we had several different versions of /etc/sudoers that were distributed by rdist to servers and clients across campus. One could edit a single file and push the changes out to all machines with a single command.

    Michael. [michael-forman.com]

  • You're still using "root"? (Score:5, Interesting)

    by Animats ( 122034 ) on Wednesday May 12, 2004 @09:47PM (#9135019) Homepage
    "root" is obsolete. Use NSA Secure Linux [nsa.gov] mandatory security features. They're in the standard kernel now.

    If you use "root", someday you will be rooted.

  • Ideas (Score:2)

    by bunyip ( 17018 )
    Initial thought - why not just email all the passwords to me?

    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.

  • How-to presentation of using sudo at large site (Score:4, Informative)

    by xmas2003 ( 739875 ) on Wednesday May 12, 2004 @10:31PM (#9135314) Homepage
    Here is a presentation on how sudo is used at a large site [komar.org] of 1,000+ machines.

    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.

    • (or futzs with the syslog configuration)

      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)

    by rdh ( 30398 )
    This may not scale well to your 300 servers, but I saw it used effectively for 20-30 servers at one company I worked for.

    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)

    by tchuladdiass ( 174342 ) on Thursday May 13, 2004 @12:28AM (#9135987) Homepage
    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.
    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 .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.

  • How bad are they? (Score:2, Informative)

    by Beaker1 ( 624539 )
    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

  • Beyond SSH (Score:3, Informative)

    by jjgm ( 663044 ) on Thursday May 13, 2004 @08:59AM (#9138184)
    > "How would you distribute root over hundreds of Unix machines to the administrators that need it?"

    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 /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:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u
    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
    • 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 :)

      If your contingency plan is so perfect, why are you afraid to describe it publicly?

  • Couple jobs back we had 300+ servers and 24 admins. Root passwords were stored in a single encrypted pgp file on a host to which we all had normal access (eg the local mail server), thus only had to remember that one (extra) password. Access was via get/put/view wrapper scripts. View script just dumped to stdout so 'view | grep somehost' would work. Modify was get/vi/put. Get just redirected 'view' to a file. Edit to taste. Put renamed old as 'old.`date +%Y.%m.%d.%H.%M.%S`, encrypted your edited file

  • cfengine2 (Score:2, Informative)

    by yarikoptic ( 571456 )
    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.

    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 why not use a "real" root password (which you can arbitrarily change as often as you like), along with a one- or two-character hash on the individual machines as part of the password (preferably known only to the root users, but really only intended to keep total outsiders from rooting every box at once).

    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
    • The problem is one of distribution and potential compromise:

      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

    • ...pick a nice, random seven-char password, and make one consistant character (say, the third) something as simple as the first letter of the machine/site using that password. Perhaps not suitable for really highly sensitive information, but a hell of a lot better

      (and easier to remember, in most cases) than "my dog's name" or "my kid's birthday".

      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

  • There is nothing in the way of technology that can guard against a truly capable and pissed-off (ex) admin.

    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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close