Date: Fri, 22 Jan 2010 13:05:05 -0500 From: Nathan Vidican <nathan@vidican.com> To: DAve <dave.list@pixelhammer.com> Cc: User Questions <freebsd-questions@freebsd.org> Subject: Re: Securing cgi scripts Message-ID: <795fc2b81001221005n2eb6cf5h454a6d2c20f4742c@mail.gmail.com> In-Reply-To: <4B59E70B.4020108@pixelhammer.com> References: <4B59BC65.3040905@pixelhammer.com> <4B59DD07.6020505@infracaninophile.co.uk> <4B59E70B.4020108@pixelhammer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Check out suExec, (assuming you're using Apache)... Please see: http://httpd.apache.org/docs/1.3/mod/core.html#user and/or http://httpd.apache.org/docs/1.3/suexec.html You can make an entire VirtualHost directive run as a different user/group. -- Nathan Vidican nathan@vidican.com On Fri, Jan 22, 2010 at 12:57 PM, DAve <dave.list@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 > 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 > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?795fc2b81001221005n2eb6cf5h454a6d2c20f4742c>