Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Best practice for executing a CGI in iwhome/httpd?
OctavianMH
Greetings all, and thanks in advance!
I was hoping for some best practice suggestions...here's the scenario.
Company A was contracted by us to create a Teamsite driven subsection of our website which was originally created by Company B. Company A decided to implement this process via a CGI script that lives in iwhome/httpd/iw-bin/bin. Which is then executed by a ui extension from within ContentCenter Pro. Company A ran into a few permissions problems when installing the module, most of which came down to the fact that the CGI script was being run by the 'iwui' user, whose privileges, in the end, had to be increased to root level (or nearly).
Company B is now beginning a development job on our website, and part of that project is upgrading to TS 6.5, we're running 6.1 at the moment. Their teamsite architect, after hearing about Company A's work, was a little exasperated at the security hole Company A created by increasing iwui's privs, and suggested that those changes were unnecessary, mentioning something about a CGI wrapper that Company A's script could've been run by, this taking iwui out of the picture .. somehow.
Now, I would love to go back to Company A and say "we're upgrading to 6.5 and are worried your module might break, since some permissions things change, etc.. maybe you should've architected it this other way...?" But I don't know enough about this subsystem to talk about it intelligently.
If this made ANY sense, can someone suggest how Company A should've executed the CGI script (this rumored wrapper..) to avoid having to elevate iwui's privs, thus opening a security hole. And is this hole a big deal, in the end, or not so much?
Thanks!!!
Find more posts tagged with
Comments
LooseCannon
Company B's architect is correct. The CGI should be run as the user not iwui. You do this by calling the CGI with the wrapper :
http://myDomain.com/iw-bin/
iw_cgi_wrapper.cgi
/myCustom.cgi
awizardly
The iw_cgi_wrapper.cgi is a setuid application written in C. It knows how to glean information about who the activating user is and allows the script to run as the user logged in. Now this may not solve all of your problems if the cgi really needs to have some root-like or more likely master like behaviors. If that is the case, then there are some other options that would require a fair amount of rework to move towards a more secure strategy.
If the cgi needs to really do root like or master like things, then it might be better doing some of those things in a workflow, where you can set external tasks to run as the root user or a master user in a more controlled situation.
We obviously haven't seen the code, but in general having a cgi run with root like permissions is a recipe for disaster. Code injection being the most common source of problems with things like perl scripts that don't rigorously test variables passed to command line tools.
Lee
Organic Inc
http://www.organic.com