From owner-freebsd-questions@FreeBSD.ORG Fri Jan 22 18:29:03 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 DD5BD1065670 for ; Fri, 22 Jan 2010 18:29:03 +0000 (UTC) (envelope-from nvidican@m2.vidican.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id AB6E68FC1D for ; Fri, 22 Jan 2010 18:29:03 +0000 (UTC) Received: by iwn7 with SMTP id 7so1192605iwn.7 for ; Fri, 22 Jan 2010 10:29:03 -0800 (PST) MIME-Version: 1.0 Sender: nvidican@m2.vidican.com Received: by 10.231.160.205 with SMTP id o13mr3416653ibx.13.1264183505773; Fri, 22 Jan 2010 10:05:05 -0800 (PST) X-Originating-IP: [136.2.1.101] In-Reply-To: <4B59E70B.4020108@pixelhammer.com> References: <4B59BC65.3040905@pixelhammer.com> <4B59DD07.6020505@infracaninophile.co.uk> <4B59E70B.4020108@pixelhammer.com> Date: Fri, 22 Jan 2010 13:05:05 -0500 X-Google-Sender-Auth: ff1d08a0c9dff26e Message-ID: <795fc2b81001221005n2eb6cf5h454a6d2c20f4742c@mail.gmail.com> From: Nathan Vidican To: DAve Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: User Questions 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 18:29:03 -0000 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 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" >