3

I have recently had to set up Drupal on shared hosting using suPHP. This is a first for me, an install where all the files are writable by the user by default. All the Drupal documentation and the Drupal built in status report will warn you of the folly of having your settings.php writable by the web server process.

Option 1: I can log into the shell and secure the settings.php by making it read-only to my own account (and the webserver account which is running as me).

Option 2: I can log into the shell and make all the files and folders read only to my own account (and the webserver account which is running as me) which may have to be changed every time I want to install a module etc. This will be kind of a pain to maintain.

My question is: Is there a significant difference in the security risk between the two options? What are the specific exploits that are possible due to having the settings file writable by the webserver process vs. the other core files?

Improve this question

1 Answer 1

Reset to default
4

Option 2 is marginally better, but if you get p0wned, a hack script will chmod the file before it tries to append to it, which pretty much renders permission-based protection useless.

Personally, I would make up shell scripts to take care of the permissions for you. For deployment, something like

find docroot/ private/ -type d -exec chmod 555 {} \;
find docroot/ private/ -type f -exec chmod 444 {} \;
find sites/default/files/ -type d -exec chmod 755 {} \;
find sites/default/files/ -type f -exec chmod 644 {} \;

Then, when you want to run drush or make updates

find docroot/ private/ -type d -exec chmod 755 {} \;
find docroot/ private/ -type f -exec chmod 644 {} \;

You should also read through Securing file permissions and ownership. This article includes a different version of shell script for fixing permissions, and uses a slightly more restrictive scheme.

Improve this answer
3
  • Good point about chmod. That would be one of the main reasons why it is best if httpd is running as a different user. I am using a script similar to what you suggested but now see that it makes less difference than I hoped. My question was trying to get at the benefit to a hacker of using a writable settings.php file as an attack method vs. the other writable core files. The built-in status report usually only complains if this one file is writable, not the others. However, in this environment I just tested changing the settings file permissions to 666 and the status report is green.
    – lolcode
    Oct 5, 2012 at 11:39
  • Settings is universally included, and rather early in the bootstrap process, is is conceivable that more harm could be done, or that your site could be directed to another database.
    – mpdonadio ♦
    Oct 5, 2012 at 13:18
  • 1
    One other idea to reduce the damage if you get p0wned is to use the paranoia module drupal.org/project/paranoia which tries to prevent the execution of php. If you find examples where it doesn't prevent execution of php, please file an issue noting that :)
    – greggles
    Oct 11, 2012 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.