Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jan 2010 12:57:31 -0500
From:      DAve <>
To:        'User Questions' <>
Subject:   Re: Securing cgi scripts
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

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.


"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

Want to link to this message? Use this URL: <>