Impossible for somephp configurations to pass the test for file system permissions

This page gives a lot of information on the topic http://drupal.org/node/244924

However, it's possible that the solution will need to come from at the apache/operating system layer which may require assistance from your sysadmin.

Hi Alan,

What I suggest you do is create 2 user accounts associated with each hosting customer that are members of the same group. So you have: user1, user2 who are members of group1. Set the webserver to run as user1 and allow the customer to login (e.g. via ssh) as user2. Set all files to be owned user2:group1 with permissions like 740 so that the customer can edit them, the webserver process can read them, and they cannot be edited by the user.

I'm in exactly the same position as Alan. I'm intrigued that Alan has tried signing up for some of the hosting companies currently listed, because I found myself wondering whether the Association will find any hosts that actually pass this particular criterion. If this really is a strict necessity, no hosts should be listed that don't pass that test, even if they offer a gold-level of sponsorship for Drupal.

The precise combination that makes this difficult is not Centos (I'm not sure that's relevant - although I, too, use Centos), but the combination of cPanel and suPHP. suPHP requires PHP scripts to run as their owner. cPanel creates one user / group that match exactly by default, so any default new account would straight away fall foul. Even if you chmod to 500, because the script is executing as the owner, the script itself (if truly malicious) would be able to revert those permissions. It's the suPHP ingredient that prevents Greg's advice in #3 from working.

The answer is not to abandon suPHP - that creates a number of major security issues on any shared environment. The answer lies in learning what tweaks can be made within the kind of environment Alan and I are working with, but also in finding an appropriate level of security for a shared web host. If nobody meets the standard, Drupal have no recommended hosts. If hardly any do, you end up with a very esoteric recommended host list, that may be very inferior in all kinds of other respects.

I'll see what suggestions people have.

Quoted from #6:

Probably it is possible to pass the test for Ubuntu/Debian systems, where virtual server's files and directories belong to different users and groups (apache, data, etc), but on RHEL/CentOS they all belong to the same user and group.

This is not an accurate statement about how Linux daemons and file system permissions work.

Somehow, Alan, whilst I agree with you, it seems to me that the problem is not with the Security Review module as such. The issue is: (i) The fact that the Drupal Association requires every test to be passed on Security Review before they'll list a host. That's their choice, but they could have chosen to disregard the test on file-writeability. As this module develops and new tests are added, it seems to me that the association should decide carefully which ones they will require. Which brings me to: (ii) The fact that the same standard does not appear to apply to existing listed hosts and prospective ones. So, in a similar vein, if a new test in SR is going to be required of all hosts, existing listed hosts should be given a period of time to ensure they conform, otherwise they lose their listing on drupal.org/hosting.

None of that is an issue for the Security Review module. I'm not sure where or how, but these issues need discussing over at http://association.drupal.org/ somewhere.

Thanks Alan - I've subscribed to that groups discussion. As you say, let's see what views and suggestions that thread throws up.

Hi Alan Mels and JamesOakley!

I have looked at the code in the security module that is running the file system permissions test. I am no PHP expert but from the comments you can see it is only trying to write a file to areas of the Drupal code base where the webserver should only have read access.

/**
 * Check that files aren't writeable by the server.
 */
function security_review_check_file_perms() {
  $result = TRUE;
  // Extract ending folder for file directory path.
  $file_path = rtrim(file_directory_path(), '/');
  $file_path = substr($file_path, strrpos($file_path, '/') + 1);
  // Set files to ignore.
  $ignore = array('..', 'CVS', $file_path);
  $files = _security_review_check_file_perms_scan('.', $ignore);

  // Try creating or appending files.
  // Assume it doesn't work.
  $create_status = $append_status = FALSE;

  $directory = drupal_get_path('module', 'security_review');
  // Write a file with the timestamp
  $file = './' . $directory . '/file_write_test.' . date('Ymdhis');
  if ($file_create = @fopen($file, 'w')) {
    $create_status = fwrite($file_create, t("This is a vulnerable directory.\n"));
    fclose($file_create);
  }
  // Try to append to our IGNOREME file.
  $file = './'. $directory . '/IGNOREME.txt';
  if ($file_append = @fopen($file, 'a')) {
    $append_status = fwrite($file_append, date('Ymdhis') . "\n");
    fclose($file_append);
  }

  if (count($files) || $create_status || $append_status) {
    $result = FALSE;
  }
  return array('result' => $result, 'value' => $files);
}

Alan, you are from Drupion and using Virtualmin to create the Virtual servers. Are you really saying that on a virtual server created by Virtualadmin all proccess and files belong to one user?

however on our CentOS server all the virtual servers are automatically created to belong to user and group of the same username. None of the users or groups for virtual servers belong to apache.

I find that a very strange situation. In all the installations to date that I have seen the web server, for security reasons runs as a separate user. In fact in the unix/linux world this is normal for all server/daemon processes to be run by its own user.

On Ubuntu (and I assume Debian also) Apache runs as the www-data user. Running
ps -Af | grep apache
on my test server shows the apache instances running as www-data

$ ps -Af | grep apache
root      2539     1  0 07:22 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2556  2539  0 07:22 ?        00:00:09 /usr/sbin/apache2 -k start
www-data  2557  2539  0 07:22 ?        00:00:03 /usr/sbin/apache2 -k start
www-data  5159  2539  0 07:30 ?        00:00:02 /usr/sbin/apache2 -k start
1000     21041 18969  0 10:24 pts/3    00:00:00 less apache2.conf
1000     21323 18969  0 10:25 pts/3    00:00:00 grep apache
$ ps -Af | grep apache

I checked and on CentOS that you are using the apache user normally runs as the apache user. So any place on this very helpful page about Securing file permissions and ownership that you see www-data you should have apache.

If I go into one of my Drupal code base directories and run:
ls -l

I can see that my files are setup permision-wise so:

/sites/all/modules:
total 36
drwxr-xr-x 8 myuser www-data 4096 2009-11-25 20:45 audio
drwxr-xr-x 5 myuser www-data 4096 2010-06-29 15:53 getid3
drwxr-xr-x 3 myuser www-data 4096 2009-01-27 18:20 multiblock
drwxr-xr-x 4 myusern www-data 4096 2010-07-01 15:43 nice_menus
drwxr-xr-x 2 myuser www-data 4096 2010-02-01 16:06 nowplaying
drwxr-xr-x 3 myuser www-data 4096 2009-09-10 19:02 plugin_manager
drwxr-xr-x 2 myuser www-data 4096 2010-03-17 23:00 rounded_corners
drwxr-xr-x 2 myuser www-data 4096 2009-04-08 17:56 stafflist
drwxr-xr-x 7 myuser www-data 4096 2010-01-12 08:40 station

The owner myuser has all rights while the group www-data does not have write access but has read rights. This is the proper setup.

If your Virtualadmin setup scripts are not providing a different user for apache to run as then you will need to modify those scripts to make that happen. You will also need to make sure that new files added to the file area that the webserver can read from are automatically given to the server group with no write permissions but read permission (www-data or apache or whatever you setup) so that the server can read them but not write to them. Google linux group sticky bit or see this page.

The security review module aside, as a web hosting provider you should be more concerned with this problem as a security risk for your hosting platform. It is very dangerous to allow the webserver (and by default a hacker of the website) to write to your Drupal code base.

If you and your technical teams at Drupion or Oakhosting.net cannot solve this problem in house then you should be seriously considering hiring someone to advise you how to.

greggles working on the security team would be definitely qualified to help you or help you find someone to advise you how to fix this security problem.

To me this problem does not seem to be impossible it seems to be a matter of proper configuration of automatic installation scripts. I hope this post is helpful and if you have any question about how to make it work let me know.

Frederick

Frederick

This is a very old thread - what prompted you to revisit it?

Things have moved on. Specifically, the Association have since decided that, whilst they will continue to test for file-write permissions, a host who failed on this one test alone would not be barred from being listed on Drupal.org. The other criteria for which hosts feature in the marketplace / advertising section of Drupal.org have also moved on.

Unlike Drupion, OakHosting.NET is using cPanel with suPHP as the handler. That specifically means that all PHP scripts run as the owner of the script. This means that each PHP file in a Drupal installation is owned by the account holder on the server, and then run with the permissions of that account holder. Sure, one could run a recursive call to "chmod o-w" to remove write permissions from those files, but because PHP is running as the owner that could be reverted from within PHP, so that protection is worthless.

Unless I've misunderstood some subtlety as to how suPHP works, there is no way to use suPHP without PHP scripts being able to write to their own directory.

You mention the security risk. On a shared hosting server, running all scripts under a single shared user (like www-data, or (for cPanel) nobody) is even more risky. It's far better to isolate a user to their own account, so that they cannot modify anything outside of that, and then to educate them as to how to keep scripts up to date so that their own account is kept safe by due diligence.

That said, the Drupal Association has recognised this, and this is no longer a bar as I said earlier.

Hi JamesOakley!

Sorry about posting on an old thread but I did not consider it that old and it was still marked active. If the issue is now a non-issue then someone should close the issue. I guess the main reason I posted is because I am looking for new hosting and came across both of your hosting companies. It was all looking pretty good till I started googling around and found the thread over on groups.drupal.org that pointed to this thread. I then figure out what security test everyone was talking about on the other thread.

Which PHP scripts are you talking about the Cpanel PHP scripts or the Drupal PHP scripts? I see that suPHP has an apache module. With this it is possible to say where suPHP is used and where php files are passed directly to the normal php handler(normally mod_php). Since the control panel and the websites it is for have different urls this would make it possible to use suPHP for the Cpanel site and use the normal PHP interpreter for the website.

Is that not possible with your webhosting? However, if this is shared hosting security-wise it would be better to use suPHP.

Regarding your statement:

On a shared hosting server, running all scripts under a single shared user (like www-data, or (for cPanel) nobody) is even more risky.

I guess the risky part question is for who is it risky? If I understand suPHP correctly it runs as the owner of the PHP file only if the group and world do not have write access and it has write access to the folder. If this account gets hacked, the hacker can write to that users folders add his or her own PHP code files.

I also see that suPHP is slow. I find people claiming that it runs 25 times slower than mod_php, but that is better than suexec at 36 times slower. However mod_php is always running and ready and a apache module. The others have to spawn a process to do the work. Security or speed?

I am guessing that Drupion since it is using Virtualmin as its control panel is running into the same thing as Virtualmin uses suexec and php_cgi or fastcgi.

After googling around a bit more on this I think I am starting to see that these type of setups (using suPHP or fastCGI/php_cgi) is a better over all security-wise for shared hosting. Is this true also for VPSes? I am not sure there is a security advantage on a dedicated server. However it still bothers me that the php script can write to a folder where php scripts can be run. Is this why people always warn about php in content and strongly advise to filter it out of content before saving?

I don't know about anyone else but I learn a lot about php and web server security in reading this thread and researching the topics it contains. Here is a good link for anyone interested in why a hosting provider would use suPHP.

Thanks for helping to educating me and God Bless!

Frederick

Frederick

First of all I apologise - I was not meaning to sound critical when I asked why you revived the thread. I was more curious. You've answered that!

You are correct that cPanel itself has its own web-serving process and PHP handler. There is no control over that. I was referring to the PHP handler used by the main Apache server that serves up client sites.

You wouldn't normally run two PHP handlers. suPHP encourages you to run it exclusively, and if it's turned off for a virtual host then that domain would simply return the source for any .PHP files - not what you want! It may be possible to configure Apache to load mod_php but defer some scripts to suPHP. cPanel's compilation of Apache doesn't allow that, and my personal view is that overly complex setups are harder to maintain and therefore to lock down and secure.

So suPHP forces PHP scripts to be executed by the user who owns them. If PHP files do not have the right ownership, it will fail and Apache will return a 500 error. This is then one additional layer to ensure that, if one account on the server were hacked, the damage would be limited to that one account - no write permissions would extend outside of that account. (I also use CloudLinux, which adds another layer to that "jailing").

suPHP is slower than mod_php, but only because mod_php can preload individual PHP scripts into memory. Again, in a normal shared environment, this wouldn't give such a benefit, as there are just too many users and too many scripts. In a dedicated (or VPS) environment the benefit would be more.

All of these security considerations do not apply in the same way in a dedicated or VPS environment, as you aren't then sharing the server with other users.

As to why the PHP input filter is best not used, there are multiple reasons for that, but they do not relate to any of this.

Glad you've enjoyed reading around and learning! Good luck finding the right setup for you!

I've updated the title to reflect that fact that it is of course possible to pass the test, it's just not if you choose to configure your webserver/php configurations.

As an issue I think this is "fixed."

I agree very much with this comment:

I guess the risky part question is for who is it risky? If I understand suPHP correctly it runs as the owner of the PHP file only if the group and world do not have write access and it has write access to the folder. If this account gets hacked, the hacker can write to that users folders add his or her own PHP code files.

I understand why traditional shared hosting companies want to run suPHP as they do it - as one way to limit the risk of one hacked site affecting another. It does, however, create a risk for an individual Drupal site that they should consider.

Agreed entirely - which is part of the wider debate of the extent to which Drupal is publicly considered to be suitable for shared hosting. I believe it is, but I'm aware of a divergence of opinion within the community.

The technical setup concerns of this ticket are still in late 2015 very relevant, and it has not been sufficiently addressed (please others correct me with a link if there is indeed a recipe for setting up Drupal on a VPS system with the now popular CentOS+cPanels+PHP combination as described by others in this and related posts and which situation I currently have).

May I suggest this indeed be reopened and renamed:

'Impossible for some suPHP-based server configurations to securely pass the test for file system permissions'

I am not commenting here on the host listing aspect, and note from @James Oakley that:

Things have moved on. Specifically, the Association have since decided that, whilst they will continue to test for file-write permissions, a host who failed on this one test alone would not be barred from being listed on Drupal.org.

@frederickjh wrote quoting Alan Mels:

Are you really saying that on a virtual server created by Virtualadmin all proccess and files belong to one user?

however on our CentOS server all the virtual servers are automatically created to belong to user and group of the same username. None of the users or groups for virtual servers belong to apache.

I find that a very strange situation. In all the installations to date that I have seen the web server, for security reasons runs as a separate user. In fact in the unix/linux world this is normal for all server/daemon processes to be run by its own user.

"Strange" indeed, I found it "strange" too on one new VPS I am using (from ServerMule in Australia BTW, and I am otherwise very pleased with it so far), but I asked their support and did a lot of research and trials (bringing me to this ticket and all the related ones) and the suPHP setup with the web server run as the cPanel user in combination with CentOS is now quite common, and Alan's description is correct. The suggestion by Greggles to try to get around it with 2 users and 2 groups is a valiant attempt but does not quite work, and is not always very convenient or practical.

I am exploring a suggestion to consider using Dynamic Shared Object (DSO) [a.k.a. older mod_php] instead of suPHP as PHP handler, might report back even if the ticket is closed.

[EDIT: Interesting external reference summary and comparison of various PHP handlers: Choosing the best PHP handler]

For those who are considering setting up a single user Apache+CentOS+suPHP+cPanel system you may wish to inspect my forum posting collating some reference links relevant to this topic; Support » Installing Drupal: SECURITY CONCERN: reference links: suitability for Drupal CMS of Apache+cPanel+suPHP on single user system (VPS or Dedicated)