Date: Fri, 22 Jan 2010 12:57:31 -0500 From: DAve <dave.list@pixelhammer.com> To: 'User Questions' <freebsd-questions@freebsd.org> Subject: Re: Securing cgi scripts Message-ID: <4B59E70B.4020108@pixelhammer.com> In-Reply-To: <4B59DD07.6020505@infracaninophile.co.uk> References: <4B59BC65.3040905@pixelhammer.com> <4B59DD07.6020505@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 nothing > 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 the > 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 least > 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. DAve -- "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 http://appleseedinfo.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B59E70B.4020108>