The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Methods to Increase Security on suPHP - Restricting who can use php.ini files

Discussion in 'Security' started by cPanelTristan, Sep 25, 2010.

  1. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    The php.ini file under suPHP

    While suPHP has various security enhancements over DSO PHP such as running processes as the user rather than nobody as well as only allowing 755 folder and 644 file permissions, the option to allow individual php.ini files is a glaring security concern.

    There are several methods that can be used to disallow users to have their own php.ini files under suPHP. The path you take will depend on whether you want to allow users to have their own in some circumstances or to restrict all accounts on the server to the global php.ini file at /usr/local/lib/php.ini location.

    Restrict all accounts to the global php.ini file

    To restrict all accounts to the global php.ini file, you would edit the /opt/suphp/etc/suphp.conf file:

    Uncomment these lines:
    Code:
    [phprc_paths]
    ;Uncommenting these will force all requests to that handler to use the php.ini
    ;in the specified directory regardless of suPHP_ConfigPath settings.
    ;application/x-httpd-php=/usr/local/lib/
    ;application/x-httpd-php4=/usr/local/php4/lib/
    ;application/x-httpd-php5=/usr/local/lib/
    To these:
    Code:
    [phprc_paths]
    ;Uncommenting these will force all requests to that handler to use the php.ini
    ;in the specified directory regardless of suPHP_ConfigPath settings.
    application/x-httpd-php=/usr/local/lib/
    application/x-httpd-php4=/usr/local/php4/lib/
    application/x-httpd-php5=/usr/local/lib/
    Save the file, then restart Apache for good measure. Now, if any account tries to put suPHP_ConfigPath into their .htaccess file, that account will return an Internal Server Error until they remove the .htaccess line. No account will be able to use another php.ini file with this as the default unless you allow the account in the php.ini file itself.

    If you have PHP 5.3+ and want to allow some accounts to have their own php.ini file

    If you have restricted all accounts globally to the /usr/local/lib/php.ini file and want to have one or more accounts bypass the restriction, this is possible under PHP 5.3 using the global php.ini itself.

    Method One: Allowing individual user_ini files

    In /usr/local/lib/php.ini file, put the following line:

    Code:
    user_ini.filename = .my.ini
    The .my.ini name can be anything. Save the file, then go to the account you want to allow their own settings and create .my.ini on the account (it can be anywhere on the account so /home/username/public_html/.my.ini)

    In the .my.ini file, you would be able to put only the changes you want to have such as register_globals = On for that account. Of note, only the PHP_INI_PERDIR and PHP_INI_USER directives are allowed in this file. Any PHP_INI_SYSTEM directives will not be changeable there.

    Method Two: Putting individual user settings into the global php.ini file

    This is the better method in my opinion. At the bottom of /usr/local/lib/php.ini file, you can actually define individual user php.ini directives with the path to that user's application:

    Code:
    [PATH=/home/username/public_html]
    register_globals=On
    post_max_size=5000M
    Here is an example putting that at the bottom of /usr/local/lib/php.ini for an account. If you try doing this in PHP 5.2, it will change the global value to the new ones rather than just that user's as PHP 5.2 doesn't support the path directive. Only PHP 5.3 will work properly to read the path to the user's application. Under this method, even PHP_INI_SYSTEM directives are changeable for that account.

    Under Method One for the user_ini file, the user does have the ability to themselves modify directives in their .my.ini file on the account. Under Method Two for the global php.ini user path directives, only the administrator of the machine could modify the directives. Of note, anyone can create their own user_ini file under Method One, but they would need to know the name in the global php.ini to do so (since you can call the file anything, so it could be called .guessme.ini instead and users aren't then likely to know the name to bypass restrictions).

    If you are using PHP 5.2 or earlier (PHP 5 only, not tested on PHP 4 nor guaranteed to work on PHP 4)

    If you are not using PHP 5.3, then the prior methods will not work. This then leads instead to the more complicated option to allow some users to have their own php.ini file and some users to be restricted to the global php.ini file.

    Under this method, you cannot have the phprc_paths uncommented, so you must have them commented out. As such, you would need to ensure /opt/suphp/etc/suphp.conf looks like the following for that area:

    Code:
    [phprc_paths]
    ;Uncommenting these will force all requests to that handler to use the php.ini
    ;in the specified directory regardless of suPHP_ConfigPath settings.
    ;application/x-httpd-php=/usr/local/lib/
    ;application/x-httpd-php4=/usr/local/php4/lib/
    ;application/x-httpd-php5=/usr/local/lib/
    Now, you would need to do the following steps:

    1. Restrict all users to the global php.ini

    Create the following directory:
    Code:
    mkdir -p /usr/local/apache/conf/userdata
    Create a file in that directory:
    Code:
    cd /usr/local/apache/conf/userdata
    vi suphp_config.conf
    In that file, place the following:
    Code:
    <IfModule mod_suphp.c>
    <Location />
    suPHP_ConfigPath /usr/local/lib
    </Location>
    </IfModule>
    Save the file :)wq). The above will restrict all current users to the /usr/local/lib location for the php.ini file.

    2. Allowing one user to have an individual php.ini

    Create the following directories:
    Code:
    mkdir -p /usr/local/apache/conf/userdata/std/2/username
    Here, std is for http. If you are also wanting this for https, you'd also create an ssl directory. The 2 is for Apache 2 and 2.2. If you are using Apache 1.3, you'd use 1 instead. The username is the cPanel username, so replace with the correct username.

    In that location, create the file:
    Code:
    cd /usr/local/apache/conf/userdata/std/2/username
    vi suphp_config.conf
    In that file, place the following:
    Code:
    <IfModule mod_suphp.c>
    <Location />
    suPHP_ConfigPath /home/username/
    </Location>
    </IfModule>
    Again, replace username with the cPanel username. This will allow a php.ini file to be placed into /home/username level only. Save the file :)wq).

    3. Adding additional directories

    Further directories can be allowed on the user's account who is being allowed to have a php.ini file. If you change the entry to this in
    /usr/local/apache/conf/userdata/std/2/username/suphp_config.conf location:

    Code:
    <IfModule mod_suphp.c>
    <Location />
    suPHP_ConfigPath /home/username/{public_html}/{folder1,folder2}
    </Location>
    </IfModule>
    This allows a php.ini in public_html as well as in public_html/folder1 and public_html/folder2 locations.

    4. Checking the changes into httpd.conf

    Create a backup of Apache in case you need to revert to it:
    Code:
    cp /usr/local/apache/conf/httpd.conf
    /usr/local/apache/conf/httpd.conf.bak100902
    Here 100902 is the date where today is September 2, 2010.

    Now, run the following command to verify the includes:
    Code:
    /scripts/verify_vhost_includes
    If each checks out OK, you'd then run this command to check these into the system:
    Code:
    /scripts/ensure_vhost_includes --all-users
    Now, rebuild Apache and restart it (rebuilding isn't entirely necessary in this instance, but I normally just do it as a precaution to ensure everything is working fine):
    Code:
    /scripts/rebuildhttpdconf
    /etc/init.d/httpd restart
    Two Important Notes on Above Method

    1. mod_userdir exception

    mod_userdir will bypasses the suPHP_ConfigPath restriction for the global php.ini file. If you have a user with the following url type:

    http://hostname/~username/

    That url will allow any php.ini files or suPHP_ConfigPath set into .htaccess to parse under mod_userdir. This is unwanted behavior, and the only current way I'm aware to prevent it would be to disable mod_userdir on such a system.

    2. New accounts aren't restricted

    Any accounts created after you have locked users into the global php.ini file using the <Location /></Location> tags around suPHP_ConfigPath in userdata location will not be restricted to it. Each time a new account is created, the following must be run after the account creation to lock that account to the global restriction:

    Code:
    /scripts/ensure_vhost_includes --all-users
    /etc/init.d/httpd restart
    Final Note: suPHP_ConfigPath in httpd.conf

    Defining the suPHP_ConfigPath line in the VirtualHost entry in httpd.conf does not restrict the account to using that path if the <Location /></Location> tags are not around it. Without those <Location /></Location> tags, if a user defines the suPHP_ConfigPath into their .htaccess file on their account in either /home/user/ or /home/user/public_html, their .htaccess entry will override the httpd.conf VirtualHost entry. You can only lock users to the set suPHP_ConfigPath by the previously described method.
     
  2. duranduran

    duranduran Well-Known Member

    Joined:
    Apr 30, 2004
    Messages:
    198
    Likes Received:
    0
    Trophy Points:
    16
    Hi, this system works with php5 and php4 ini files (DIFERENT .ini files) ?
     
  3. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Hello,

    The methods discussed do not work for PHP4 as these are only tested on PHP5 (5.2 and 5.3). I have not tested and really had no plans to test PHP 4.

    I do appreciate you bringing that question to my attention, since I've now revised the guide to indicate that the 5.2 or earlier is PHP 5 only due to PHP 4 not having been checked / tested.

    Thanks.
     
  4. Infini-Servers

    Infini-Servers Registered

    Joined:
    Jan 9, 2011
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    with this method, for a user can we do:

    [PATH=/home/user/public_html]
    disable_functions =

    So that disabled functions do not affect a particular account?
    Or are there only certain functions you can change per user. (php 5.3+)
     
  5. gkgcpanel

    gkgcpanel Well-Known Member

    Joined:
    Jun 6, 2007
    Messages:
    217
    Likes Received:
    0
    Trophy Points:
    16
    cPanel Access Level:
    DataCenter Provider
    Sadly, this method 2 does not seem to work. As a test, I have already uncommented the lines under the phprc_paths in /opt/suphp/etc/suphp.conf file to lock down so that all users are forced to use the system wide php.ini.

    I am running PHP 5.3.6

    PHP 5.3.6 (cli) (built: Jun 24 2011 15:37:00)
    Copyright (c) 1997-2011 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with the ionCube PHP Loader v3.3.20, Copyright (c) 2002-2010, by ionCube Ltd.
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

    I added the following lines to /usr/local/lib/php.ini:

    [PATH=/home/username/public_html]
    register_globals=On
    post_max_size=5000M

    I then went to /home/username/public_html and created a test.php file that simply calls phpinfio();

    Then ran this from the command line:

    php test.php | egrep 'register_globals|post_max_size'
    post_max_size => 8M => 8M
    register_globals => Off => Off

    As you can see, it still only read the system wide php.ini file, so method 2 does not seem to work...

    I will now try method 1 and let you know the results.
     
  6. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Method 2 works fine for me under suPHP. I'm running PHP 5.3.6:

    Code:
    root@host [/home/tristan/public_html]# php -v
    PHP 5.3.6 (cli) (built: Jun 19 2011 11:48:58) 
    Copyright (c) 1997-2011 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    I put this at the very bottom of /usr/local/lib/php.ini file:

    Code:
    [PATH=/home/tristan/public_html]
    register_globals = On
    post_max_size = 5000M
    I then put a phpinfo page at /home/tristan/public_html/php.php with this in it:

    Code:
    root@host [/home/tristan/public_html]# cat php.php
    <?php
    phpinfo();
    ?>
    When I go to phpinfo() it shows the changed values. Screen print attached. Of note, you get local and master values in the phpinfo return. I didn't check it via command line, but I suggest checking your page in a browser in case you are somehow misreading what it should be outputting by how you are searching for the information.

    Screen shot 2011-06-24 at 4.16.37 PM.png
     
  7. gkgcpanel

    gkgcpanel Well-Known Member

    Joined:
    Jun 6, 2007
    Messages:
    217
    Likes Received:
    0
    Trophy Points:
    16
    cPanel Access Level:
    DataCenter Provider
    Tristan, you are correct. The browser does show the correct values. Thanks...
     
  8. goodmove

    goodmove Well-Known Member

    Joined:
    May 12, 2003
    Messages:
    624
    Likes Received:
    0
    Trophy Points:
    16
    If using per-user php.ini for php5 only, can we leave the php4 line uncommented in suphp.conf?
     
  9. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Yes, you don't have to uncomment the PHP 4 line in the file. If you only want the PHP 5 one to be restricted, simply uncomment the PHP 5 line.
     
  10. luisp

    luisp Well-Known Member
    PartnerNOC

    Joined:
    Jan 17, 2003
    Messages:
    57
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Portugal
    cPanel Access Level:
    DataCenter Provider
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Hello,

    We have PHP 5.2 in a few servers, but the method provided for this version doesnt work for us. The idea is not to allow customers to run their own php.ini, but instead control what they can use through the global php.ini ( just like the 5.3 works ).

    Any idea of how can we do this?

    Thanks in advance for your help.
     
  11. luisp

    luisp Well-Known Member
    PartnerNOC

    Joined:
    Jan 17, 2003
    Messages:
    57
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Portugal
    cPanel Access Level:
    DataCenter Provider
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Hello,

    A few minutes reading the suphp documentation and found a solution :)

    Thanks anyway.
     
  12. quietFinn

    quietFinn Well-Known Member

    Joined:
    Feb 4, 2006
    Messages:
    998
    Likes Received:
    10
    Trophy Points:
    18
    Location:
    Finland
    cPanel Access Level:
    Root Administrator
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Maybe you could share the solution?
     
  13. Lestat

    Lestat Well-Known Member

    Joined:
    Sep 13, 2003
    Messages:
    199
    Likes Received:
    0
    Trophy Points:
    16
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    PHP 5.3.10 (cli) (built: Mar 15 2012 18:14:32)
    Copyright (c) 1997-2012 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with the ionCube PHP Loader v4.0.12, Copyright (c) 2002-2011, by ionCube Ltd., and
    with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
    with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH


    none of these methods worked for me.
     
  14. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Please provide actual details on exactly what you've tried. I am uncertain what the php -v information is providing to us.
     
  15. WhiteDog

    WhiteDog Well-Known Member

    Joined:
    Feb 19, 2008
    Messages:
    118
    Likes Received:
    0
    Trophy Points:
    16
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    I have just tested with PHP 5.3.10 using the "old" method. This still works for me.
    The "new" method with the .my.ini I don't like vecause you can not alter PHP_INI_SYSTEM variables with it (see PHP: List of php.ini directives - Manual).

    I will update phpinimgr to be able so it:
    - Can update all custom php.ini files with the default one but preserving the directives under [phpinimgr_custom]
    - Removes all entries found in the custom directive from anywhere else
    - allows you to UNCOMMENT entries in the custom directive, and removes their uncommented counterparts from anywhere else in the file (so you can e.g. put ";extension=homeloader.so" as a custom directive, and then "extension=homeloader.so" is removed).

    EDIT: oops, this was intended for this thread: http://forums.cpanel.net/f185/how-can-i-protect-php-ini-suphp-127537-p3.html :)
     
    #15 WhiteDog, Mar 19, 2012
    Last edited: Mar 19, 2012
  16. ergohost

    ergohost Member

    Joined:
    Jul 12, 2009
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Bit confused.

    Im running a server that will have a mix of my sites and client sites, Im running suphp.

    Is this still necessary using php 5.3+?

    If it is those lines would work if placed in postwwwacct yes? (They seem to)

    I run php 5.3+ and I used the method of locking out user php.ini and referencing user accounts from the end of php.ini with path statements.

    Is it still necessary to run the ensure_vhost_includes commands on my system?

    I dont fully understand the locationmatch part and if this is also necessary on my setup.
     
    #16 ergohost, Apr 10, 2012
    Last edited: Apr 10, 2012
  17. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Is what still necessary using PHP 5.3+? If you want to restrict users to the global php.ini but allow certain users to bypass the global settings, then using path statements at the end of the global php.ini to allow those users (as described in my guide) to have different settings is the best way to do it. If that's what you are already doing, and it sounds like you are, then yes it is necessary to do it that way.

    The lines indicated to ensure_vhost_includes are also required to run on new account creation, which could be done via postwwwacct

    As for the locationmatch part, what part is that? Are you talking about the <Location></Location> tags or something else?
     
  18. ergohost

    ergohost Member

    Joined:
    Jul 12, 2009
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Im running php 5.3.10 with the path statements in global php.ini and the lines in postwwwacct.

    Sorry for not being clear, yes I meant the last part of the guide relating to <Location></Location> tags.
     
  19. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    Since you are using the global php.ini method with path statements, you don't need to use the method for PHP 5.2, since you have PHP 5.3+. Those <Location></Location> tags relate to forcing PHP 5.2 to use the global php.ini other than for some accounts such as the following:

    You wouldn't use both methods (PHP 5.3 and PHP 5.2) on any server, since you'd pick the method for the PHP version you have. You can disregard the <Location></Location> comments for that reason.
     
  20. digiscape

    digiscape Member

    Joined:
    Oct 15, 2003
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

    I am using the method below with PHP 5.3.10 & WHM 11.32.2

    It is not working and is overriding the defaults (as it would with PHP 5.2)
    And making changes to PHP configuration in WHM will comment out individual settings



     

Share This Page