Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?795fc2b81001221005n2eb6cf5h454a6d2c20f4742c>