I wanted to get others opinions on providing root access to vendors. I have a vendor that is claiming to need full root sudo access to complete a one time system set up for their software. The system is on our corporate network and we never provide this level of access. Not only that, they want to do the install remotely.
We all know that the claim to need the full root sudo access is complete BS since they only need the sudo access to do what needs to be done. However they claim that there is too much involved to not have full access.
What are your thoughts? Have there been situations in your environments when you've provided full root sudo access? If so, did you take certain precautions (remove from corporate network, have one of your team sit with them, etc)?
If you as a system administrator grant anyone root access to your network (remotely or on-site) and they screw up, you are betting your future and the financial security (including all private data and IP on every system accessible on your network) and the reputation of the company you work for on the trustworthiness of that person.
Can you isolate the systems this person will be accessing AND verify 100% that they have a not installed any back doors or data leaks on the systems they have touched before you reconnect those systems to the rest of your network?
How much do you trust this vendor and all of that vendor's employees and contractors?
What makes you sure that they don't need root access? There are of course commands, that can be only issued as root. Sure they can be added to sudoers, but they would have to list every one of them so you can allow them but this might be somewhat tideous.
It can also be of course for the ease of installation, that they ask for root access, which I do understand.
Yes, there are installations that can only be done as root or at least partially. When this is the case, there is usually some admin sitting next to them to at least check what they do. It should be inhouse and via remote session. That could be a criteria, that a software is only allowed on your systems when it can be setup with an own user in the selection process of a software before it is bought.
Though - there can always come code on your machines, that could do harm in terms of spying or destroying/manipulating data.
I doubt strongly, that anyone does a full code check of the software that is being installed on their systems even if it does not run with root permissions. For example - does anybody know what is in the complete code of an Oracle RDBMS installation? It is not even open source.
Even if it was open source software, who has the time, knowledge etc. to check every line of code if it has anything malicious in it.
Also usually most servers are placed in an internal network, protected by one or more firewalls, as long as you are no hosting company (they might have some mechanisms too, but I have no experience about it).
So any gathered data usually can not be sent outside your companies network as it would bounce against the firewall and hopefully alert the network guys for irregular communication.
There is still other ways to get the data out of the company, but this is broad and complex thing, which should be an issue for the security guys in the company.
And as Don says, it is always a question of trust and also of legal rules and liability in contracts with vendors which takes a big part in what you let them do or not.
You sometimes have to make compromises between security and get the stuff up and running.
Something like an IDS (AIDE, Tripwire, ...) can also be very good to check what will be modified on your systems. Also an audit system can come in very handy to log, what they do for later issues. These together with a good firewall handling will make ones life a tad less stressful in terms of security. Though you are right to have concerns and not let it pass half asleep
I might be a bit old fashioned here, but it used to be part of the SA's job to ensure that no one other than the SA had access to the root account. It also used to be drummed into SA's that any application that had to be installed as root was basically flawed.
From a security perspective any such application was a likely candidate for an exploit, so should not be allowed. As to giving an external vendor root access, not going to happen on my watch - why?
A real example - I have had a black box system delivered from a major international telecommunications company, complete with two back door (UID 0:GID 1) accounts setup. Additionally in the applications directory there was a SUID file called xyzzy which turned out to be a copy of the /usr/bin/ksh binary.
I would trust no person outside the systems admin team, where the requirement was to have the root password - in some cases I wouldn't trust people in the team, but that was for a different reason.
Nothing, perhaps. But if someone - in general - needs root access then he has at least the rights management got completely backwards. And this begs the questions: where else have the developers of the software - to put it in polite words - strayed from the path of pure truth?
Yes, and these are the exceptions to what i said in general above. The most common of these exceptions is arguably having to install kernel extensions (i.e. Oracle Database, SAP). But with careful planning these parts can be isolated into a single script (like rootpre.sh in the Oracle installation) and handed over to the Sysadmin to be executed. The software provider needing root access himself is either out of pure lazyness ("its so much easier if i can do whatever i want") or bad design and/or implementation of the software. This doesn't even take malevolent intents (which also could be the case) into account. And by "malevolent" i do not only mean outright criminal theft of data or the like! How about "yes, of course we installed this tracker for the number of installations of our competitors software X, because knowing how many of these you use helps us tailoring our service better to your needs"? Would that be what you want on your system?
Amen, brother!
Again with the exceptions stated above: yes.
And there are two other points you should take into account: first, it is YOUR job as Sysadmin to guarantee the integrity of the system. How can you do that, after someone else had root access? You can check for all backdoor methods to be installed you can imagine, but ultimately you don't know if there isn't a method you do NOT know of.
and second: as the admin you are responsible for the daily operation of the system. If someone sets something up - how would you repeat the process in case of desaster? Suppose the server breaks and you need to install a new one: shouldn't you be able to do it?
To be able to do it in most cases boils down to: at least once did it! So you should not let them remotely install anything anyways, but insist that they send a person to assist you while you install the system (and document the process). This way you will be much more likely to repeat this should anything go southwards.
@Bakunin:
I generally agree.
It could have been the OP had already installed the software with a non-root user as a test - just out of interesst, that's why I asked.
But in the end (my past reality ;)) you get such software on your desk and it has to be installed. So far I or coworkers got such tasks always communicated orally and not written.
It comes down to install it, maybe with the vendor, or deny the installation unless the management, or whatever guys bought that fancy software, will take the risk.
And to be on the clean side, you would need to notice the management of possible dangers and get a kind of written assurance from them just in case something goes wrong. But to be honest, I don't remember any coworker, who demanded this from his boss for any Software before he started the setup and I do not know if this would keep one free from guilt at court.
root or not - software can still be malicious, dangerous or any less degree of a threat/unwanted behaviour. With root it usually can harm the system it is installed on but hopefully not more system, depending on the environment and setup. So if possible only a "quarantained" system might be a start as already said by Don.
Though what is if there is a timer that it automatically does it's tricks after a defined time/date, when it is somewhat sure to be installed in a production environment where it has locally or over the net access to precious data etc...
A tracker like mentioned basically does not need root. But I know what you mean
Is there the possibility you will be able to install the solution in the same timeframe as the vendor?
Do you have standard operational fallback procedures?
Does the vendor have demonstrable experience installing the solution in similar environments?
We do let vendors have access to some of our systems, but only those systems their work requires.
Significant configuration changes are approved by ITS stakeholders, announced, and scheduled for a predetermined downtime.
Any "significant" configuration change is preceded by full backup, allowing fallback in the event installations don't go according to plan.
For some vendors, it's a ride-along affair, with the remote session established and monitored by a local admin. This is also a learning opportunity for the admin, and can help establish a stronger working relationship with the vendor.
