Rob Thompson

One of the things I’ve recently been doing, is looking into ways of deploying Apache that can improve security in multiple user web environments. The scenario is that there are 100′s of different users who all want to develop sites under their own virtualhost configs with server side scripting abilities. Also, these same workers often need to work in groups on the same set of code. Making this work at a basic level is relatively easy, but making the environments antonymous from each other and secure is another. Here are some of the issues.

Autonomy

With a single web service running, if there are any server-side scripting packages installed such as PHP, Perl, etc., a single user can crash, hang, over-utilize or otherwise degrade the web service for everyone.

Security

Poorly written code and vulnerable server software potentially compromises the security of the entire installation and the system itself. As the number of sites increase, the possibility that this will cause a problem gets even greater as it becomes very difficult to audit the security of the all the code that is running under the different sites.

UNIX Group Limitations

Another security issue with a single server install has to do with the fact that is is necessary to allow the Apache uid/gid access to read everyone’s content. This is difficult to do in large environments while keeping the user areas separate.

While group permissions may seem like just another scriptable/auditable system administration task, there are some real limitations with respect to what is possible. The first thought may be to enforce file permissions like ‘uid=user group=www perms=rwxr—–’. This works ok, but there are still some fairly large security problems since group ‘www’ needs to read anyone’s files. Users could potentially simply write a PHP script or the like to read anyone else’s data through the permission of the web server, which still needs to be able to read anything.

Apache does deal with group membership for the www user in the /etc/group file, so this is a way to make the files between users and groups a bit more secure by doing something like the following:

www:*:100:
sitea:*:101:www
siteb:*:102:www

And set file permissions to look like:

uid=user, gid=site, perms=drwxr-----

However, this still does not solve the PHP/Perl execution problem and you still may run into another issue: The maximum number of groups that you can have on a UNIX machine is usually limited to somewhere between 16 and 32 groups! On some systems you can expand this number to be larger, however, this limitation is imposed because of a limitation in NFS, whereas the protocol can only deal with a limited set of groups. Of course, this is going to be an issue if you have a large number of groups, or maybe even using NFS.

One way, that avoids the /etc/group limitation, is to add a little more security by creating a couple of “trustable groups” for which you assign all new users. For example, you could do something like the following

www:*:100:
groupa:*:101:www,usera,userb,userc
groupb:*:102:www,userc,userd,usere,userf

And set file permissions to look like:

uid=user, gid=groupa, perms=drwxrws---

This way, virtual host directories are assigned the permissions of a specific group and users in groupa will not be able to modify any virtual hosts in other groups. This all still works since www is a member of each of the work groups. Note: Apache needs a restart to pickup new group assignments.

This seems like the best you’re going to get (at least as far as I can figure out) without doing something else that would change the architecture of your setup entirely. Here are a few options that I’ve found that do just that:

A Single Apache with FastCGI and suEXEC Wrappers

The combination of FastCGI and suEXEC wrappers for Apache is a nice way to segregate different server-side processes to run under different IDs. As opposed to standard CGI, the FastCGI interface re-uses spawned interfaces, which largely avoids the resource problems and speed issues associated with CGI.

Multiple Apache Instances with a Front-end Proxy

Another way to go about creating antonymous server sites is to create a single apache instance for each DNS name that you are hosting and create a single proxy on the port 80 front-end to deal the incoming traffic. The front-end proxy handler could be done with Apache + mod_proxy or Apache + mod_rewrite.

Summary

There does not seem to be a magic bullet for dealing with secure, antonymous Apache installations with many users. FastCGI, suEXEC and other tools offer some ways to make hosting environments relatively secure, but certainly at the cost of resources and complexity.