Securing cgi scripts
nathan at vidican.com
Fri Jan 22 18:29:03 UTC 2010
Check out suExec, (assuming you're using Apache)...
Please see: http://httpd.apache.org/docs/1.3/mod/core.html#user and/or
You can make an entire VirtualHost directive run as a different user/group.
nathan at vidican.com
On Fri, Jan 22, 2010 at 12:57 PM, DAve <dave.list at pixelhammer.com> wrote:
> Matthew Seaman wrote:
> > DAve wrote:
> >> Good morning all,
> >> I have been working on an issue here where I am being asked if we can
> >> support letting clients install and run their own CGI scripts on a
> >> shared vhost. I have tried sbox and cgiwrap, both which worked, but they
> >> cannot stop the one test of reading the /etc/passwd file.
> >> Forgive my ignorance here, but I thought CGIs were gone long ago and
> >> have not messed with them in over ten years. If a client really needs a
> >> specfic CGI script hosted, I check it out thoroughly and install it
> >> where they cannot reach it. Those instances are very very rare.
> >> It looks to me like the only way to keep a client contained is to run
> >> their CGIs chrooted. Would this be correct?
> > CGI programs run in the OS filesystem context, so there's generally
> > to stop them reading /etc/passwd. They are essentially the same level of
> > risk as an unprivileged user login account.
> > Mind you, pretty exactly the same thing applies if you let your customers
> > supply their own PHP or perl or other programs which run using an
> > interpreter
> > embedded in the apache process: they can access anything accessible to
> > web server process.
> > I should point out that unprivileged users are *meant* to be able to
> > read /etc/passwd -- it's /etc/master.passwd that has the sensitive stuff
> > in it.
> > In fact, the bigger problem with running CGI programs from a shared
> > webserver is that they generally all run using the same security
> > credentials; those of the web server (www:www by default) -- which
> > potentially lets all your different customers tread on each others
> > toes. suexec(8) is the stock solution to that problem.
> > If you really want to keep your customers properly separated, then send
> > them to jail(8). While giving them each a separate jail with a full
> > install of apache etc. certainly does work, it implies dedicating at
> > an IP per customer. You could avoid that by still keeping a single
> > apache instance but use something like an fCGI process per customer
> > running each in separate jails hanging off the loopback i/f.
> All understood. I have had the conversation before with the PHB about
> the accessibility of /etc/passwd and the rest of the system. Our PHP
> instance is well locked down and they cannot do much harm, but I still
> have to audit periodically, if just for my own peace of mind.
> I suspected there was no new tool or wrapper to further secure a CGI
> process beyond chrooting it or putting the entire site within a it's own
> jail. But.. I have to look and ask because I WILL be asked if I did.
> Thanks for the response.
> "Posterity, you will know how much it cost the present generation to
> preserve your freedom. I hope you will make good use of it. If you
> do not, I shall repent in heaven that ever I took half the pains to
> preserve it." John Adams
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions