Security implications of having files owned by the apache user?

Question

Currently running a LAMP instance that developers are using for a variety of webapps. I have the following scenario:

• Multiple developers need access to create and modify files under /var/www/html
• The developers need to be able to access each other's code in case they are out on vacation, sick, etc.

My thoughts were the following:

1. For each web application (directory) under /var/www/html, recursively change the owner to 'apache' and the group to a 'developers' group. Set the permissions at 570.
2. For each file under /var/www/html, recursively change the owner to 'apache' and the group to a 'developers' group. Set the permissions at 470.

Keeping the files and directories as read-only to the Apache user is a good security practice, but is having such files owned by the Apache user a bad one? My concern was around what would happen if Apache got hit by a 0-day vulnerability or something of the sort.

If anyone has a more elegant way to do this, I'm interested in hearing it as well.

Answer 1

Restrict the daemon with MAC

No matter how you cut it, wrapping Apache in a mandatory access control layer like AppArmor or SELinux is a good first step. That will allow you to restrict the daemon's allowable operations even if otherwise has permissions to do so. That will prevent Apache from ever modifying your files.

Use version control with automatic checkouts

If every developer has access to git and the production branch is automatically checked out by the web server when it is updated, you will have control and history of everything that is loaded as well as instant verification that everything is what it should be.

Permissions

The downside of making Apache the owner of the files is that Apache could theoretically chmod those files. For that reason, making the data directory and files within owned by another user has a benefit unless you expect Apache to alter the directory. If you do, try to separate directories for expected dynamic content and content that Apache should never update.

Answer 2

You're absolutely right, keeping the user running the webserver process, in your case apache isolated from writing to the webroot is a good idea. It is one of the basic hardening guides for a reason. If the user can write to the files or directories, then it makes it easier for a malicious user to modify the filesystem. One thing you aren't taking into account is how the ownership of the filesystems work.

The user who owns a file can always write to it. This seems contradictory, but is in place so that the user can do things such as overwrite or delete the file.

If, for your business process, the developers require direct write access to the live web files I would modify your recommendations to this:

My thoughts were the following:

1. For each web application (directory) under /var/www/html, recursively change the owner to another account such as nobody or root and the group to a developers group. Set the permissions at 575.
2. For each file under /var/www/html, recursively change the owner to another account such as nobody or root and the group to a developers group. Set the permissions at 474.

This will allow the apache user to read the files, thus allowing httpd to serve the files, while preventing it from modifying the files.