Command Center

Many of you may be aware that SharkSpace is now implementing suPHP on shared hosting servers, which was announced here recently. Through this blog, we will try to explain to you what suPHP is about and how it is beneficial for everyone.



Securing a shared hosting server is a challenging task as it has to be secured from outside and from inside a website. Vulnerable scripts or incorrect permissions can cause compromises from inside a server. PHP has built-in features to help, but ultimately it’s the wrong place to address the problem. Apache has built-in features too, but the performance cost of these features is prohibitive. This is where suPHP, created by Sebastian Marsching comes to the rescue.



Like Apache’s own suexec, suphp is a solution that allows PHP to run as the user and group that owns any particular website on a shared hosting server. Technically, suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the UID of the process executing the PHP interpreter.



suphp consists of two components:



* mod_suphp, an Apache module that replaces mod_php
* suphp, a setuid binary that replaces Apache’s suexec



Every time a PHP script is run, suphp has to fork Apache and then execute another copy of the PHP/CGI binary. This approach provides the absolute security benefits that we seek. It means that if a script contains a vulnerability, and got exploited, then only that particular user will be affected.



suPHP has the following advantages:



* PHP runs as your user/group
* PHP files can have permissions of 640 (hiding things like passwords from other accounts)
* Files/folders written by PHP are written as user/group (no Apache or other global user)
* Custom php.ini file per site (can add/remove security options)



Please note that suPHP does not allow permissions 666 and 777.



Some users make use of .htaccess files to set php configuration lines using php_flag var setting. Having a .htaccess file use the php_flag directive will result in a 500 error be produced. PHP flags no longer work in the .htaccess file. If you need to enable things such as register globals you can follow the below guide:



In .htaccess under public_html, add the following:



suPHP_ConfigPath /home/user/public_html

order allow,deny
deny from all


Note: You must change user to your account username.



Create a php.ini file under public_html add any of the below settings that you need:



register_globals = On
upload_max_filesize = 30M
post_max_size = 30M
memory_limit = 30M
upload_tmp_dir = 30M
max_execution_time = 180



Using a php.ini file may cause issues if your scripts use Zend Optomizer or IonCube encoding. You then just need to add the following to your php.ini file to resolve the issue:



Note: this may not be needed. Please test before using.



[Zend]
zend_extension=/usr/local/ioncube/ioncube_loader_lin_4.4.so
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.2.6
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.2.6
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so



For the PHP settings you do not have in your php.ini file, PHP will use our default configurations. It will not use the server php.ini but rather a default one. You may need to set other settings. You may create a phpinfo.php file in public_html with the beginning and ending php tags and the following in between to see any changes by browsing it:



phpinfo();