First a clear statement; there is absolutely no doubt (based on both personal experience with a compromised pre-Drupal-7.32 site and on a review of literally 100s of discussions of this matter both on Drupal.org and wider WWW) that running suPHP (which forces the web server to run PHP script as cPanel/filesystem user) has serious security implications for all PHP-based CMS systems, including Drupal.

The simplest statement of this is that experts agree that while suPHP is convenient for containing any damage to within the scope of one user on a multi-user system (and thus popular with web hosting companies setting up a server for general use), using suPHP may offer weaker security vs PHP-driven CMS platforms than some other PHP handers that run the web server as another user (which user such as www-data, apache, webserver etc. typically only has write access in the case of Drupal to /sites/xyz/files with a special .htaccess), but not to a user's entire filesystem. Using suPHP with an insecure (older) version of Drupal means a hacker can get "the keys to the (filesystem) castle" within a cPanel user's entire filesystem zone. And every version of Drupal is, sooner or later, older.

Use of suPHP is convenient w.r.t. file ownership of uploaded files and Drupal-generated files, and in combination with the Drush command line tool run as the main cPanel user via SSH. By contrast, when using some other PHP handlers there are inconveniences concerning file ownership of for example cache files written by the web server when not as user, but there are ways of dealing with that.

Not using suPHP may (depending on how your VPS/Dedicated host has initially set things up) have consequences for operation of other cPanel/WHM systems like backups.

There are a lot of pros and cons to consider, and to help those setting up a single-user, single/multi-site VPS or Dedicated Server with cPanel (typically with CentOS) I offer the following links that might help you make this difficult decision, "to suPHP or not", in awareness of this wisdom I bumped into today in somebody's signature on a forum:

"Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." - Laurence J. Peter

I start with some external and not specifically Drupal related links, where the ownership consequences for PHP-driven Drupal are identical:

- Why suPHP Is Insecure for a Joomla Website (2012)

- Are All Your Joomla PHP Files Hacked?

- Does suPHP make a single site server less secure?

On Drupal.org:

- Security Review » Issues: Impossible for somephp configurations to pass the test for file system permissions

- Security Review » Issues: Cant pass the file directory permission test

- Security Review » Issues: How does the Presence of suPHP Affect Recommendations About File Permissions

- Support » Post installation: Drupal needs 'files' to be 777 :( [2007]

- How you you manage your web users, groups and file system permissions??

The list goes on and on. It is likely one of the most discussed security concerns in the entire Drupal CMS community.

Darren, Webel IT

Comments

greggles’s picture

I think this is a good post, Darren. Thanks for bringing your thoughts and the list of resources together.

webel’s picture

For those who indeed are considering moving from suPHP "back" to older DSO (mod_php), I have now compiled some preliminary yet very detailed instructions on exactly how to go about it TIP: Drupal6/7 permissions setup compatible with DSO (mod_php) 'nobody' web server mode on CentOS+WHM/cPanel under Drush maintenance. It is for a specific, yet quite common, VPS technology combination, but hopefully the basic principles apply to other systems. The security indications for such a move are strictly for when you don't share your server machine with other customer users.

@greggles Some elements of the described recipe are influenced by your suggestions in related posts, however my recipe is for using the 'nobody' user/group "as is" without assignment to say an extra 'webserver' or 'apache' or 'www' group.

Webel IT Australia, "Elements of the Web", Scientific IT Consultancy,
For PHP-driven Drupal CMS web sites, Enterprise Java, graphical UML, UML Parsing Analysis, SysML, XML.

greggles’s picture

There are multiple methods to achieve a secure setup. I'm not too familiar with the nobody group, but I definitely support exploring a variety of recipes to achieve the goal.

vegantriathlete’s picture

I will definitely be reading through the information on this post. I've got a client running on a VPS that is running suPHP. I'm not able to get APC running properly without switching to DSO.

Skin’s picture

Hello, I'm not a big expert, and after reading this post I still not understand why running suPHP + CentOS + cPanel has serius security implications.

For example I understand that

Using suPHP with an insecure (older) version of Drupal means a hacker can get "the keys to the (filesystem) castle" within a cPanel user's entire filesystem zone. And every version of Drupal is, sooner or later, older.

, so I use for exaple DSO, and I have an old and insecure script I' will have the entire server/cpanel accounts compromised? If I understand well in this situation suPHP is 100% more secure: better one user fully compromised or all user?

Thanks

Skin’s picture

Sorry, I've read more accurately ( english is not my first language ) , and I think you are right.