potential security concern with non-root level account

Posted on 2006-07-13
Medium Priority
Last Modified: 2010-04-22
I'm assigning a lot of points (I think) in hopes that I can distribute the points according to the number of answers I get. I hope that's not considered lame.

Recently as a systems admin I was asked to create a non-root level access account on a web server. The environment is two web servers with one of those servers also providing the staging environment. This was put into place before my time and I've fought ever since to get the client to aquire a staging server on separate hardware. Also, there is only port 22 access open to the environment from the client's IP and our IP. Also, obviously port 80 is open to the world.

The question is or the debate is whether creating a non-root level account for the client on one of the web servers is a security risk worth worrying about. The account would have ssh access to the box and be able to make changes to the directory structure underneath the staging directories.

My concerns are that not only is this a bad idea because we have the burden of making sure the sites that are hosted are available but also that maybe there is something I'm overlooking in terms of write access to the filesystem. This new user would only have write level access via a group membership to /var/www/html/staging while being barred the same access to the production environment that is located under /var/www/html/production. What are the potential problems with this scenario? Also is it trivial to gain root level access once an account is created?
Question by:ekeyser
LVL 24

Accepted Solution

slyong earned 672 total points
ID: 17105153

looking at your posting, I realized that you don't really trust your client very much (which is a good thing as a system admin).  Running the staging and production server on the same hardware already opens up a whole lot of security issues like they can upload exploit codes into the staging and I am not sure whether the codes are being reviewed before moving to production system.

Coming back to your question about non-root access, the best bet I could think of is doing a chroot environment to cage them into just /var/www/html/staging so that they won't move out from there.

One point that I am concerned about is the web servers, are they different web servers running?  You also have to check the permission of the staging web server.  If someone can upload a piece of exploit code and ask the web server to run it, the system can be quite easily compromised.

LVL 18

Assisted Solution

decoleur earned 664 total points
ID: 17116155

you are right there are issues with this configuration.

allowing your client non root access to a production system is a "bad" idea.

If I have SSH access to a system on your network, I can cause problems for you:
For example I can use the SSH service on the server as a gateway into your network and gain access to any machine that is accessible on the network to your production machine using a technique called tunneling over SSH.
If I have SSH access to a system on your network I can upload files onto your machine using SCP that I can use later on.
If I have SSH access to your machine I can execute commands that could call upon local binaries (that I jut put there) or remote services that could provide the ability to perform an escalation of priviledges that would result in the gaining root level access on your machine.

allowing your client to use the production system as a staging environment is also a "bad" idea.

For example if I am using a machine for staging an application that I am developing, I am doing a lot of work on it, this can cause problems.
I could be developing a dynamic application that has a scripted environment that could become unstable and lock up the application or the machine.
I could be developing an application and shutdown the wrong service and kill the production application.

... i could go on for a while.

IMHO it takes too much time to set up a chroot jail and it is not fool proof, restricted bash can also be gotten around.

I would look at getting a virtualization server and set up a vmware image for the client and let them have at it, that way you can mitigate their impact on other resources... prefereably in a different DMZ from your internal and production environment. And if they hose it, you can always roll back to a previous snapshot.

hope this helps

LVL 42

Assisted Solution

noci earned 664 total points
ID: 17118202
Non production environments should NEVER be on production systems...

At least assuming that code gets a review when placed on the production system.
Normaly you build an DTAP train.
Development   - clear enough... (per developer if needed)
Test - Tests (integration tests) all development parts put together (development team is in the lead)
          (still fixing bugs etc.)
Acceptance (frozen code, this is the release to go to production when ready. test in jurisdiction
   of customers, systems management & auditors, production alike server. it passes or flunks as a whole.)
Production ( noaccess except for maintenance & backup).

These needn't be real servers of course, Virtal servers (Xen, VMware, LPAR, Virtual Server, User mode Linux) might help here too. Some of these virtualisation tools might also have extra benefits
Xen & VMware-ESX allow moving executing virtual machines from one physical system to another without stopping the virtualized systems.

Also there are a lot of exploits in the world that get a moderate severity because you need local access to the system to exploit them..., but if you have LOCAL access, these kind of Vuln's are HIGH risk.


Featured Post

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
Fine Tune your automatic Updates for Ubuntu / Debian
Watch the video to know the simple way to remove or recover or reset lost or forgotten passwords of Outlook PST file. With Kernel Outlook Password Recovery tool such operation is very easy to perform. It is a freeware with limitation to use with 500…
To export Lotus Notes to Outlook PST or Exchange and Domino Server files to Exchange Server or PST files with ease, go for Kernel for Lotus Notes to Outlook conversion tool. Through the video, you can watch the conversion process. A common user with…

568 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question