Virtual Subhosting security issues
It is important to consider some of the security issues that
relate to Virtual Subhosting. Because the Virtual Subhosts operate
in the same Virtual Server Environment, CGI scripts that are executed
by any Virtual Subhost will inherit privileges to access any directory
or file in your Virtual Server directory hierarchy.
For example, a malicious Virtual Subhosted client could write
a simple script to remove all of the files on your Virtual Server (not
a "good thing"). Another script could send the contents of your
"~/etc/passwd" file to a remote e-mail address where "weak" passwords
could be decrypted. If your login password is susceptible to a
dictionary crack, a subhosted client could effectively steal shell
access away from you.
It is recommended that you do not offer full cgi-bin access to your
Virtual Subhosted clients unless you have complete trust in them (even
then, they may accidently cause damage to your Virtual Server). We
recommend one of the following alternatives:
- Provide stock CGI scripts in a directory you control
Most web sites do not demand a great deal of custom CGI programming.
It is likely that you could provide a library of "stock" CGI scripts
which your subhosted clients could then use. A sample composition
of such a library might include: a counter, a guestbook, and a
generic form processor. You would store these scripts in a
subdirectory of your cgi-bin directory (e.g. vhlib). You would
then configure each of your Virtual Subhosts to use this cgi-bin
directory by adding the following lines to their
<VirtualHost>
definition:
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/vhlib/
- Configure the cgi-bin directory separate from the Virtual Subhosts'
home directory
Another alternative is to provide your subhosted clients with a cgi-bin
that is not a subdirectory in their home directory. This would prohibit
them from uploading and executing any arbitrary script. Instead, the
subhosted client would e-mail you the script, you would review it, and
then install it into their cgi-bin directory (which can be configured
to be a subdirectory of your main cgi-bin directory). An example is shown
below:
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/SUBDIRECTORY/
Where the subdirectory SUBDIRECTORY becomes the cgi-bin directory for the
subhosted client (you may want to use the same subdirectory name for both the
~/www/vhosts and ~/www/cgi-bin to keep things neat and tidy).
We recognize that in most cases it is likely that not only are you
providing your clients with hosting service, but you are also designing
their web content and writing their CGI scripts as well. So this
discussion may not be applicable to your specific situation, but it
is still an element to remember should you decide to expand the scope
of your services in the future.
|
