Handing Over Root Passwords to Clients and Contractors?

waa asks: "I have a client who's system I remotely administer. This particular machine has been up performing its various duties 'problem-free' for 4 months (since last kernel patch/fix). The client has, on-site, a consultant who pretends to know things he certainly does not know; Linux systems administration for one, and they now have requested the root password. Since it is their system, I'd imagine they have every right to the root account, however I know for sure that as soon as this is handed over, things will start to mysteriously malfunction, and I will get an emergency call to get them back in service (or worse, I will be blamed; ie: back-stabbed). I'd rather not have to troubleshoot and fix a completely preventable, and possibly complex problem. What are peoples' experiences regarding this situation? How have you handled it? Is some form of 'release from responsibility' contract in order? I need some advice soon" In situations like this, communication with the client is important. If you ever run into a situation like this, talking to the client and informing them of the potential problems is always a good idea. If any problems happen afterward. Start documenting them, and pass them back to the actual client if things start to become a problem. Anyone else care to weigh in?

Comments

Tripwire + backup...

[Bryan Andersen]

First backup the hole system as is and keep a copy for yourself. If that isn't possible, backup the configuration files and any data files you can fit.

Tripwire is your friend. Run tripwire on all files (even ones known to change). Save the tripwire file on both the system and keep a backup copy. When you get a support call you can use this to check what the guys have changed. For the most part you can run tripwire without checking checksums, just length, data, perms, etc. This will give you a list of new, changed, and deleted files. Not doing the chacksums lessens some of the utility of tripwire, but it gets you a list fast as tripwire dosen't have to read the file in.

Security tool can be used for your bennifit. They aren't just for security. When administering systems for developers who have root I always use tripwire on their systems. Often it tells me what they are changing so I can keep on top of their needs.

How about logrotate, kerberos, CVS, groups

[QuietRiot]

I've been working as a student systems administrator for a computer lab at Cornell for the last 3 years on linux and NT systems. We've got lots of students with root access to some machines quite critical to the operation of the lab. We have had, on many occasions, situations where a lack of communication and multiple people working on the same project/server/whathaveyou, shall I say, stepped on eachother's toes. I'm not sure if we ever implemented any of these, but I've done some thinking about it! (especially after a day's worth of work on a config file gets blown away by a vi edit from another guy with root who doesn't know what he's doing....) Anyway, here's a few things you could do...

1) Set up a cron job to backup configuration files
You could either write a simple script to tar up /etc/* or whatever other files your clients might want to fowl up. Or you could use the logrotate program. It's a flexible solution to manage log files and could be used to tar up and compress periodically the files you'd like to backup should anything get messed up.

2) Use the "wheel" group
to allow only certain users to perform administrative functions on files you chown root.wheel. You could also do this for a "web" group (#chgrp -R web /home/www) or anything else to give access to certain files for certain people. Instead of "giving them root," ask them which users want to have control over which sets of specific files on the system, make groups for each set of files, and add the users to the group that need access. This would allow you to track down more easily who modified a certain file, since only a few people may have had access to it. (easier finger pointing basically). This is much better than knowing that a bunch of people could have done it, and getting blamed for it yourself.

3) Setup sudo
Edit /etc/sudoers

4) Use process accounting

5) Set up a simple kerberos5 installation
This allows you to give root [or any other administrative-type account function] access to certain users via a ".k5login" file. This allows you [root] to simply add users who are allowed root access [to kerberized services] by putting their principal [system user account name] in root's .k5login file. You needn't give them the root password. They can just login as themselves and they will be allowed to use their own tickets to access kerberized services that require a "root" principal. All access is logged so that backtracing who did what and when would be possible. Note: This may be an unnecessarially complex method to implement. It can however be used for a wide variety of services and is considered quite secure and flexible, particularly for large networks. It won't work for general file access, but if you can kerberize some of the services you'd like to administer, this would help immensely.

6) Tell them to make backups before they change anything or implement a CVS system
on all config files that anyone would want to changeCVSing config files would force documentation and allow you to revert to any previous incarnation of your system if something somehow "broke."

Hope this helps!