...
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 featuerss 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>(Unfinished beyond this point)