Threats 

The threats we need to protect against are:

1. An attacker exploiting an httpd or other service vulnerability to take over the apache account.
2. An attacker exploiting a web application vulnerability to take over a user account.
3. A user accessing privileged information belonging to another user, or changing data belonging to another user, or an attacker doing the same after succeeding at (2).
4. A user exploiting a local root vulnerability to take over the machine, or an attacker doing the same after succeeding at (1) or (2).

1. httpd exploit

By exploiting a remote vulnerability in httpd, an attacker could gain control of the apache account.  A similar attack might take place against any other service running on the machine, possibly resulting in immediate root access if the other service runs as root.

Such an attack would likely disrupt the functioning of the entire service while the vulnerability responsible for the attack is uncovered and the machine is reinstalled.  User data could be lost or corrupted and might need to be restored from backup, although the Apache account should not have access to most user content.

Mitigation: run as few services on the machine besides httpd as possible.  Be alert to publically known httpd vulnerabilities and patch them as quickly as possible.

 2. Web application exploits

Web applications are generally implemented in PHP or another scripting language and are not usually subject to buffer overflow attacks.  Nevertheless, they have traditionally contained a rich variety of vulnerabilities, generally of one of the following forms:

• Shell command injection: execution of shell commands containing unsanitized user input, allowing attackers to execute arbitrary shell code
• SQL injection: execution of SQL queries containing unsanitized user input, allowing attackers to execute arbitrary SQL code
• Inclusion vulnerabilities: inclusion of other scripting code via a variable path containing unsanitized user input, allowing attackers to execute arbitrary scripting code
• Cross-site scripting: display of unsanitized HTML provided by one user to another, allowing attackers to execute Javascript code on another user's browser in the security context of the web application

Moreover, these vulnerabilities are the subject of widespread and frequent exploits.  Mitigation of this risk will come in two forms:

1. Reduce the frequency of compromises.  To the extent that we foster development of custom-written web applications, educate developers about these attacks and how to prevent them.  For off-the shelf web applications, provide cookie-cutter installations, monitor security sites for known exploits, and have a framework for fixing the cookie-cutter installations users have performed.
2. Reduce the severity of compromises.  No matter what we do, user account compromises will be endemic to our service, so we need to provide good tools for recovering from attacks (frequent user-accessible backups, for example) and to ensure that attacks do not spread to other users of the service.

3. User boundaries

This is a complicated topic and is best considered in pieces.  This is also an area where we are in conflict with the world of web hosting at large.  Most commercial web services do not insulate users from one another, and most web application installation instructions only concern themselves with instructing users how to break down what barriers exist, not how to work within them.

3a. Static content

Public static content (e.g HTML files) is not an issue as long as it is only writable by users other than the owner.  However, some number of users will naively set their static content to be group or other-writable.  It may be necessary to protect such users against themselves.

Private static content (anything protected by a .htaccess file) must be readable by the apache user if httpd is going to be able to serve it normally.  This means making those files world-readable, which is an issue if it allows other users to read the content without going through httpd access controls.  If all users are placed within the same group, the files can be protected against other users by making them not group-readable--assuming users have no ability to read the content from the apache account using dynamic content features (see below).  Again, it may be necessary to protect users against themselves.

Recommendations:

• Place all users in  the same group.
• Set the default umask to 073.
• Run a system-scanning process which masks all user file permissions with ~073 (removing all group permissions and all world permissions except reading) unless the user opts out by placing a magic flag file in the top level of the home directory.
• Do not allow users to execute dynamic content using the apache uid.

SIPB's scripts.mit.edu service has, for various reasons, opted to make static content read by the uid of the content owner, rather than by the apache accounts.  This decision comes at a hefty penalty in performance and complexity, and should not be necessary in our environment as long as we adhere to the above principles.

It may be possible to use SELinux to more robustly isolate user accounts from one another.  More research is required.

3b. Dynamic content

Dynamic content features in a web hosting environment include CGI or FastCGI scripts, scripting modules (mod_php, mod_perl, etc.), and server-side includes.  Most of these mechanisms are not limited in power; they allow dynamic content to take arbitrary actions including executing shell commands.  mod_php can be configured to be limited in power, but not in a robust manner, and generally only at the expense of compatibility with pre-existing web applications.

It is traditional in web hosting services to execute dynamic content as the apache account, possibly within the httpd worker process itself.  This practice is grossly insecure; although the apache account may be unable to modify any system files, all user dynamic content becomes undifferentiated in terms of what actions it can take.  If my dynamic content can read my database password from a file in my home directory, your dynamic content can do the same.  The commercial web hosting provider I evaluated provided the option of executing dynamic content as your own uid (using cgiwrap) so that you could protect files from other users, but none of the cookie-cutter installation scripts they provided made use of this feature.

<incomplete>