Vendor root access

 
Thread Tools Search this Thread
Top Forums Programming Open Source Vendor root access
# 1  
Old 06-10-2016
Vendor root access

All,

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)?

I really appreciate any thoughts on the subject..

TIA,

Herb
# 2  
Old 06-10-2016
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?
This User Gave Thanks to Don Cragun For This Post:
# 3  
Old 06-10-2016
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 Smilie

Last edited by zaxxon; 06-10-2016 at 06:55 AM.. Reason: update after some additional thoughts
This User Gave Thanks to zaxxon For This Post:
# 4  
Old 06-10-2016
Hi Herb,

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.

Regards

Gull04
This User Gave Thanks to gull04 For This Post:
# 5  
Old 06-10-2016
Quote:
Originally Posted by zaxxon
What makes you sure that they don't need root access?
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?

Quote:
Originally Posted by zaxxon
There are of course commands, that can be only issued as root.
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?

Quote:
Originally Posted by gull04
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.
Amen, brother!

Quote:
Originally Posted by gull04
It also used to be drummed into SA's that any application that had to be installed as root was basically flawed.
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.

I hope this helps.

bakunin
# 6  
Old 06-10-2016
@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 Smilie) 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 Smilie

Last edited by zaxxon; 06-10-2016 at 10:08 AM.. Reason: typo
# 7  
Old 06-10-2016
Questions:
Is this a business requirement?

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.
Login or Register to Ask a Question

Previous Thread | Next Thread

10 More Discussions You Might Find Interesting

1. OS X (Apple)

Root access in OSX 10.12.2.

Mac users... I updated this MBP from OSX 10.12.1 to the brand new OSX 10.12.2 two days ago. A week ago I installed the Xcode suite. Now the QT shell audio capture in another recent thread is broken when exporting a file. It gives an error in a window, paraphrasing, The action is not... (4 Replies)
Discussion started by: wisecracker
4 Replies

2. Ubuntu

Root access that can't change root password?

We are having a little problem on a server. We want that some users should be able to do e.g. sudo and become root, but with the restriction that the user can't change root password. That is, a guarantee that we still can login to that server and become root no matter of what the other users will... (2 Replies)
Discussion started by: 244an
2 Replies

3. SuSE

Auditors want more security with root to root access via ssh keys

I access over 100 SUSE SLES servers as root from my admin server, via ssh sessions using ssh keys, so I don't have to enter a password. My SUSE Admin server is setup in the following manner: 1) Remote root access is turned off in the sshd_config file. 2) I am the only user of this admin... (6 Replies)
Discussion started by: dvbell
6 Replies

4. Shell Programming and Scripting

How to give root access to non root user?

Currently in my system Red Hat is installed. And Many user connect to my machine via SSH Techia Terminal. I want to give some users a root level access. Can anyone please help me how to make it possible. I too searched on the Google but didn't find the correct way Regards ADI (4 Replies)
Discussion started by: adisky123
4 Replies

5. UNIX for Dummies Questions & Answers

How to allow access to some commands having root privleges to be run bu non root user

hi i am new to unix and i have abig task. i have to \run particular commands having root privileges from a non root user. i know sudo is one of the way but i need sum other approach kindly help Thanks (5 Replies)
Discussion started by: suryashikha
5 Replies

6. AIX

root access

Hello I have a question. I have a box with Aix 5.3 but I want to disable root access direct from any terminal or console. I mean If I want to login to 10.10.10.10 login:root password ********* Root access is not permited Which file I have to edit. to the users first login with... (4 Replies)
Discussion started by: lo-lp-kl
4 Replies

7. Solaris

Security of root access

Hi, The security auditor give a this statement , what to do ? On my solaris system (S10) "The User ID "root" should not be used on the system - the su and the priviledged account should be used from each administrator for accountability purposes" What to do ? (3 Replies)
Discussion started by: falcon16
3 Replies

8. Shell Programming and Scripting

To What files root does not have access to??

Hi, I just wanted to know to what files root does not have access, not even read....I read that .profile for any user is the only file which root cannot access is it true..??...If we have to use passwords and ID's in a script can we use them in .profile and call them as parameters..??? ... (3 Replies)
Discussion started by: mgirinath
3 Replies

9. SCO

root access

We have SCO 5.0.5 and can't log into system as "root". The system indicates the password is incorrect. No one knows what happened. How can we resolve this issue.. Are there files we can restore from backup...? Any suggestions would be appreciated. Thank you.. (2 Replies)
Discussion started by: RBurer
2 Replies

10. Linux

how to access root priveliges if root password is lost

wish to know how to access root password it root password is forgotten in linux (1 Reply)
Discussion started by: wojtyla
1 Replies
Login or Register to Ask a Question