httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Grace" <rub...@earthlink.net>
Subject Re: [users@httpd] Virtual Hosting security issues
Date Sun, 01 Dec 2002 03:44:05 GMT
From: "sunil sharma" <apache_fan@yahoo.com>
To: <users@httpd.apache.org>
Sent: Tuesday, October 15, 2002 10:44 PM
Subject: [users@httpd] Virtual Hosting security issues


> Hello Friend
>
> I am very worried about my virtual host security
> issues
>
> On my server their are near about 550 virtual host's
> are configured
>
[snip configuration example]

> if I upload any php script with file open function
> suppose in test.com
> i can read  the content of test1.com thought their
> user and group are different
> and also i can view the whole directory structure of
> my server
>
> I tired by giving "DocumetRoot ~" like this
> but it is not working i am finding the solution but
> can any body help me in this problme?
> So it their any way from which i can stop this?
> anybody can help in this?
>
> Thanx in advance

This is the very reason I dont' have my own free-for-friends PHP hosting up
yet.  It's a major security issue and the fix is kind of expensive.

SUexec works wonders for this, however, SUexec is only useful for situations
when you're running a CGI script, etc.  It won't work for Apache modules, so
you need to use it with the PHP CGI module and may need to workaround for
any others you are using as well.  The downside here is you either have to:
 1 - Make a copy of the PHP CGI for each user (SUexec will only work if ONLY
the user it runs as can modify the file its running)
 2 - Hack the SUexec code (despite all the warnings that scream "You really
ought to not modify this file") to remove the 'must-be-owner' restriction.
(I only recommend doing this if you understand the security complications
behind this -- most notably, giving your webserver user the ability to
effectively 'su' to most any user (SUexec will refuse to access a system
account or root.))

The far superior way (that might not work yet) would be to use the
still-experimental.  Perchild MPM in Apache 2.  This basically allows you to
bind each virtual host to its own user/group.  Since the actual Apache
process runs as that user/group (instead of relying upon SUexec for
scripts), this works with modules as well as actual CGI binaries in the
webspace, and it allows you to make the entire WWW directory for that vhost
readable/writable by the owner and not by anybody else (if you choose to do
so).  The downside is (if I'm not mistaken -- I don't know the specifics as
to how it works) you'll end up with at least one Apache process running as
each user (plus 1 to listen for connections and forward them to the right
connection, plus 1 that runs as root that creates new connections which in
turn setuid themselves).  The downside is all your modules need to be
thread-safe, and Perchild may not actually be working yet and probably
should not be used on a production server.  Track its progress at
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/experimental/perchild
/perchild.c.  If you opt to give this a try, let me know how it works out ;)
I tried this many many months ago and didn't have luck then, but Perchild
has evolved alot since then.  If it works for you I'd like to know because
then I can start looking into it again myself.

-- Daniel Grace
Certified 99.9996% lurker


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message