Securing cgi scripts
dave.list at pixelhammer.com
Fri Jan 22 17:57:55 UTC 2010
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
> 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
More information about the freebsd-questions