Security Basics mailing list archives
Re: Apache: limiting the execution place
From: "Tim Greer" <chatmaster () charter net>
Date: Tue, 17 Jun 2003 09:42:04 -0700
From: "exon" <exon () home se> To: <security-basics () securityfocus com> Sent: Tuesday, June 17, 2003 2:16 AM Subject: Re: Apache: limiting the execution place
I don't quite see the point, or I've misunderstood what you're asking for. Do you want to block local users from seeing what global users can? What hinders the local users from getting it anyway through the webserver instead?
They want it so users can't use FTP, shell, or a CGI or PHP script to view, browser nor access other user's files and directories. Like he said, set the permissions to 710, set the group as the Apache group, and run SuEXEC (for both CGI and PHP (PHP as CGI--and a patch can make it so you needn't make any changes to the PHP script)). This will shut out any other access by any other users via shell, FTP, web server processes (such as PHP or CGI scripts) and so on. This also allows you better control to limit the memory, CPU, number of processes and running time for CGI and PHP scripts, both, per VirtualHost block. Yes, PHP as CGI is slower and no, it won't work for mod_perl, etc. Most web hosts with multiple users on shared servers (in my experience) rarely run any modules other than mod_php that would prevent the above method from working. It's a small trade off/more overhead from CGI, (but) that will make it more secure and under better control of the processes so users can't crash your server with idiot scripts through the web server. And, besides, any user that would get enough hits per Vhost to actually need to use PHP as a module to prevent the overhead from becoming an issue, _should_ have their processes limited anyway--so in reality, running it as CGI will only give you more control and the user(s) better security. The only real downside then, is that if they have an exploitable script (and there's always some ignorant user that does), their own files are more at risk as the CGI/PHP processes run as their own user. Of course, it's better just that user being the victim of their own ignorance than any other user that has to allow write, create, modify or read access to specific files or directories that just happens to be unfortunately enough to be on the same server. So, I'm all for solutions like this. Of course, as I said in another recent post, Apache 2.x and (the) MPM (module) will solve this problem, so you can run per-user Vhosts without sacrificing performance, security, nor control and administrator needs. The stupid user vs. exploit in their own script will always be a problem, but that's their problem. :-) -- Regards, Tim Greer chatmaster () charter net Server administration, security, programming, consulting. --------------------------------------------------------------------------- Evaluating SSL VPNs' Consider NEOTERIS, chosen as leader by top analysts! The Gartner Group just put Neoteris in the top of its Magic Quadrant, while InStat has confirmed Neoteris as the leader in marketshare. Find out why, and see how you can get plug-n-play secure remote access in about an hour, with no client, server changes, or ongoing maintenance. Visit us at: http://www.neoteris.com/promos/sf-6-9.htm ----------------------------------------------------------------------------
Current thread:
- Apache: limiting the execution place Nebi Gurbanov (Jun 16)
- Re: Apache: limiting the execution place Chris Ess (Jun 16)
- Re: Apache: limiting the execution place Boris Dragovic (Jun 16)
- Re: Apache: limiting the execution place exon (Jun 17)
- Re: Apache: limiting the execution place Jonas Acres (Jun 17)
- Re: Apache: limiting the execution place exon (Jun 18)
- Re: Apache: limiting the execution place Tim Greer (Jun 18)
- Re: Apache: limiting the execution place Tim Greer (Jun 17)
- Re: Apache: limiting the execution place Chris Ess (Jun 16)