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: