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

[cPanelTristan]

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

I wondered what you were talking about here. All methods work and should work for the version of PHP intended. Anytime someone has claimed it doesn't work, it was because the user did not properly setup the method or tried it on the wrong PHP version.

 

[digiscape]

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

As you stated in your first post Tristan "PHP 5.2 doesn't support the path directive." this was all I was referring to

I have upgraded to PHP 5.3.13 with Apache 2.2.22, neither method 1 or 2 for PHP 5.3 are working for me

There's really not much you can do wrong using the path directive method

 

[cPanelTristan]

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

Actually, there is something you can do wrong using the path directive method. First, you could not be using suPHP or FCGI, which isn't likely but it would be something wrong. DSO doesn't support that method.

Next, under suPHP, you could not have done this part:

[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/

Then restart Apache after doing so. If you do not modify /opt/suphp/etc/suphp.conf file to restrict to the global php.ini file, then what happens is that users can override your settings in their own individual php.ini files.

 

[digiscape]

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

I'm using suPHP and respective lines uncommented in /opt/suphp/etc/suphp.conf to force users to use global ini

I do have this working, but if I look at the settings in WHM > PHP Configuration Editor it is actually showing the user directive values, and if I make any changes here it will use those values, commenting out the user values.

Example
- Added user directive register_globals = ON and this successfully applies to the single account
- View WHM PHP Configuration Editor and it will show register_globals is ON (when its actually off)
- Save in WHM PHP Configuration Editor will overwrite global value switching register_globals ON

 

[cPanelTristan]

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

Why are you using PHP Configuration Editor? If it successfully applies to the single account, then it is working. You would want to use phpinfo on the different accounts (one with a PATH directive and one without one set) to see the results. I do not ever suggest to anyone to use the WHM PHP Configuration Editor.

 

[digiscape]

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

Why use cPanel at all

Thats fine just as long a people know, using this means you can no longer use WHM editor

 

[cPanelTristan]

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

Anytime you do a customization of this sort, it would be expected you are going to have to do things manually. Manually means in command line not using GUI tools. If you could use the WHM PHP Configuration Editor for any of this, it would have been noted in the guide. It can be a bit misleading to state that my guide doesn't work for any of the methods when it does actually work and what didn't work was an area I never even suggested using in the guide haha

 

[nike.stars]

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

does this guide also actually disable ini_set capability to use custom php.ini ?

 

[cPanelTristan]

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

To confirm, do you have ini_set in disable_functions in the global php.ini file?

Also, what PHP version are you using? If you set the /opt/suphp/etc/suphp.conf to not allow custom php.ini files under PHP 5.3 by uncommenting the phprc_paths, then you shouldn't be able to override that via another method. If you can, then suPHP itself is the issue for allowing that to occur.

 

[discountnetz]

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

Hello

I use your instructions and register_globals post_max_size or with a user account work very well.

I have been trying to load various extensions specifically I try the memcache and memcached extension reload

[PATH = / home / username / public_html]
extension_dir = "/ usr/local/lib/php/extensions/no-debug-non-zts-20090626"
extension = "memcache.so"
extension = "memcached.so"

Unfortunately it does not work. To use is not generally possible extensions in [PATH = / home / username / public_html]?

Best Regards
Jan

 

[cPanelTristan]

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

Hello Jan,

The one issue I've heard reported is the one you are describing. You cannot set these custom extensions for those users, right. You'll either have to have a PHP module extension available for all users or not available to any users. They can't be set via PATH directive.

Thanks!

 

[goodmove]

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

What type of permissions and ownership should a php.ini file in user's space (in /home/user) have?

 

[cPanelTristan]

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

I'm uncertain this is related to the existing guide, since this appears to be a general question about php.ini settings. The ownership should be the username, so username:username while the permissions should be 644 like most files.

 

[goodmove]

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

I'm uncertain this is related to the existing guide, since this appears to be a general question about php.ini settings. The ownership should be the username, so username:username while the permissions should be 644 like most files.

It is related in the way that username:username will allow the user to modify the php.ini. This can be undesirable in some circumstances. If the admin wants to retain control over the contents of the config file in the user's space, the ownership should be set to root:username.

 

[cPanelTristan]

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

It is not related to only suPHP and is not applicable to this guide. This guide's specific purpose has to do with using the php.ini file itself by calling the directives. It doesn't have to do with hacking the php.ini file. Feel free to open up your own guide on other security mechanisms for all PHP handlers.

 

[copernic2006]

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

Hello,
In php.ini, I disabled fsockopen and I would activate only a few accounts, so I followed the proposed solution as follows:

[PATH=/home/username/public_html]
fsockopen = On

Unfortunately, this solution is not working, any help is welcome?

For information:
PHP: 5.3.17
Apache: 2.2.23

 

[Astral God]

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

The php.ini file under suPHP

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:

[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.

Hi.

I've tried this, but, this is not applied to ONE account but GLOBALLY - even in PHP Configuration Editor on WHM these "new" values are updated.

I'm using PHP 5.3.18.

Thanks.

 

[borgia]

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

If I understand well you need php.ini by user no? This thing can be easy using Apache templates and hooks. Like this you can use php.ini for each account. So you can disable "fsockopen" for one particular account and the rest to be enable. If this is what you want let me know I'll explain.

 

[Astral God]

Somebody knows why values under [PATH] are becoming global ?

I really need to use this feature !

Thanks.

 

[hostnex]

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

Somebody knows why values under [PATH] are becoming global ?

I really need to use this feature !

Thanks.

Define this way in php.ini

[PATH=/home/user/public_html] upload_max_filesize= 100M