14

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.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
am4
  • 141
  • 1
  • 3

2 Answers2

10

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.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • Thanks - I like keeping SELinux in the mix if possible. I've used it a few times, but I'm a bit at a loss on this one: is there a specific boolean/setting that SELinux uses to allow Apache to not perform `chmod` and `chown` operations, or does it explicitly happen by virtue of SELinux being enabled? – am4 Dec 20 '11 at 18:15
  • @am4 I was more focusing on controlling read & write than permissions changes. However, one can't change directory permissions to a file entry without write permissions to the directory. In that way, it would be restricted. SELinux is fine-grained enough that there may also be a way to restrict that system call itself, but I don't know it immediately. – Jeff Ferland Jan 10 '12 at 15:48
9

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.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91