From owner-freebsd-questions@FreeBSD.ORG Fri Jan 22 17:57:55 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BEF1065670 for ; Fri, 22 Jan 2010 17:57:55 +0000 (UTC) (envelope-from dave.list@pixelhammer.com) Received: from smtp2.tls.net (smtp2.tls.net [65.124.104.105]) by mx1.freebsd.org (Postfix) with ESMTP id 635578FC0A for ; Fri, 22 Jan 2010 17:57:55 +0000 (UTC) Received: (qmail 1299 invoked from network); 22 Jan 2010 17:57:54 -0000 Received: by simscan 1.2.3 ppid: 1263, pid: 1296, t: 0.1733s scanners: attach: 1.2.3 spam: 3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on smtp-2.tls.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=7.0 tests=ALL_TRUSTED,TVD_RCVD_IP autolearn=disabled version=3.2.1 Received: from 64-184-8-201.bb.hrtc.net (HELO ?192.168.1.46?) (ldg@tls.net@64.184.8.201) by ssl-smtp2.tls.net with ESMTPA; 22 Jan 2010 17:57:54 -0000 Message-ID: <4B59E70B.4020108@pixelhammer.com> Date: Fri, 22 Jan 2010 12:57:31 -0500 From: DAve User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 'User Questions' References: <4B59BC65.3040905@pixelhammer.com> <4B59DD07.6020505@infracaninophile.co.uk> In-Reply-To: <4B59DD07.6020505@infracaninophile.co.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Securing cgi scripts X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:57:55 -0000 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