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.

tiered support

[gascsd]

Not sure about in private environments, but in academia-land, we (previous position) setup a tiered support level.

Tier 1: only we (comp supp group) have the root pw. for nt, we would also be the only ones with the local admin password

Tier 2: root password is shared. on nt, local admin password is shared, or they (customer) has the local admin password and we still have domain admin rights; all 9x machines and macs

Tier 3: we have no root/admin access at all.

Depending on the tier determined when we would get to them. If a grad student installs some software and hoses the machine, but it's tier 3, it may be a few weeks until we get to it. tier 1 machines we'd get to that day, or the next. tier 2 was generally in a few days.

Like I said ... that's in academia-land, where customers aren't paying (at least here). Tell your client, "if he fubars the machine, don't look at me" ... whether they go with that or not, who knows. doesn't hurt to ask

Give them what they asked for...

[Steev]

Change the name of the user with UID 0, and create a user account called "root".
Give them the password :)

Well, here's one arragement I've seen (GM and EDS)

[Surak]

GM hires EDS to do all their sys admin stuff. They wrote it into the contract that GM doesn't have the root password, only EDS. However, some machines that are not EDS maintained only GM has the password. There may be other machines where GM and EDS share the password.

In any case, anytime only EDS has the password, these are the machines that get maintained in the most timely manner. Machines where EDS does not have the root password, or where the root password is shared don't get as much service. So it is to GM's advantage to have most of their machines be purely EDS managed, as those are the machines where the serivce level agreements are pretty much guaranteed.

Psuedo Root

[cybermage]

Express your concern about stability to your client. Find out from your client what they want to use the password for. Explain the difference between routine administration (e.g. adding users) and server maintenance (e.g. kernel patches) and suggest that you set-up psuedo root access for routine tasks and then backup the files the psuedo account can change.

It is not uncommon to provide clients with a 'root' account that lets them configure the services they use (e.g. POP3, Samba) without giving full access to things like 'make'. Understanding how to do this is left as an exercise for the reader.

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!

Root Isn't Takin' a Turn With Your Sister

[InitZero]

The system belongs to the customer. It's just root. Give it to them. If it breaks, you fix it. If they break it, you fix it. That's what you get paid for.

How many people do stupid things to their cars? Have you ever heard a mechanic consider not giving a customer his keys after a repair has been made? Of course not. The mechanic would go out of business. Your job is to fix computers. Do it.

To protect your reputation, however, make sure there are no direct root logons. By making folks logon as themselves first then su'ing to root, you know whose pecker tracks are all over the issue.

InitZero