Going over to suPHP

[Parcye]

Hi,

After some problems with permissions and exploits I want to make the step to suPHP.

But as the server is now finaly up and running again and I don't want to put people through more outages, I want to be very well prepared before I go over to suPHP.

I found some howto informatio, but that is back from halfway into 2006 (2 years ago thus). As much has happend since in the WHM/cPanel world I was wondering if somebody can provide me from accurate information and point out some things not to forget and to keep an eye on.

Thank you.

 

[MattDees]

Generally, moving over to SuPHP is painless, there are (as you know) a few pitfalls:

The first thing I would keep my eye open for, is the fact that SuPHP will not execute scripts, or script inside of directories with world or group writable permissions. Before moving, I would advise running "find /home -name '*php" -perm 777" to see what will no longer execute. You can add "| xargs chmod 755" to the end of this command to automatically change these, but this is not always advised.

The other thing that you need to keep your eye open for is .htaccess files and php.ini's. You cannot have php_flag or php_value in .htaccess files with SuPHP. Rather you will need to put "SuPHP_ConfigPath /path/to/php/ini" inside of the .htaccess and then create a php.ini with the desired values in it.

 

[electron33]

Thanks a lot Matt.

I'd appreciate if there're any other potential issue you or anyone else can share.

 

[verdon]

File ownership is also important. If there were scripts that were uploading things (like images) before, they will likely be owned by 'nobody'. You need to change these to the user in question.

I used these commands to change ownership and fix permissions. I was not as cautious as Matt

chown -R username:username /home/username/public_html/* ;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chmod 644 {} \;

Also, if you use a local php.ini file, it will over-ride all your custom settings in the global php.ini file and not just the one or two local directives. So, be sure to copy over any other custom settings from the global php.ini to a local one.

 

[mtindor]

SuPHP can have an adverse effect on performance - at least in my experience. Of course, I run SuPHP on all servers regardless. it makes perfect sense. But just be aware that web delivery of content may not be as robust if you are running SuPHP.

mike

 

[verdon]

SuPHP can have an adverse effect on performance - at least in my experience. Of course, I run SuPHP on all servers regardless. it makes perfect sense. But just be aware that web delivery of content may not be as robust if you are running SuPHP.

mike

Same experience for me. For me, the cause was actually that you can't use eaccelorator or other php accelorators when using suphp.

However, I upgraded my hardware and the performance issue isn't really discernible anymore. Mike's right though, if you have an older cpu and smaller amount of ram, you're really going to notice the difference.

 

[adapter]

is there any way to use SuPhp with FastCgi? i am try SuPhp on my Quad Core server and i see that all the Php process have a high cpu Usage, someone reach also 40% of usage, any way to optimize it?

 

[mambovince]

I used these commands to change ownership and fix permissions. I was not as cautious as Matt

find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chmod 644 {} \;

Hi,
Also considering SuPHP
Would you mind explaining what those 2 commands actually do, and can they be run server-wide instead of one account at a time?

Many thanks,

- Vince

 

[verdon]

Hi,
Also considering SuPHP
Would you mind explaining what those 2 commands actually do, and can they be run server-wide instead of one account at a time?

The first one finds all items in /home/username/public_html/ that are of the type directory and then executes chmod 755 on them. The second command does something similar for files.

You could use a small shell or perl script to do it server-wide, but I don't have an example at hand and am not smart enough to do it off the top of my head. If I find an example, I'll post back

 

[rustelekom]

Generally, moving over to SuPHP is painless, there are (as you know) a few pitfalls:

The other thing that you need to keep your eye open for is .htaccess files and php.ini's. You cannot have php_flag or php_value in .htaccess files with SuPHP. Rather you will need to put "SuPHP_ConfigPath /path/to/php/ini" inside of the .htaccess and then create a php.ini with the desired values in it.

It's a big security hole. Any user can change main php settings and completely lost security settings which set by server admin. I had inform about this Cpanel team about year or more ago and for unknown reason your team ignore this warning. Not all WHM users has a experience to manually recompile suphp with correct settings and i don't know why Cpanel team ignore such important problem. It's require only one directive in suphp module code to be changed and may take about minute or less to get suphp work securely.
Without such correction suphp main idea (security) just absolutely lost and user who are used suphp just alive with open securty hole (and it is too big to just ignore it).

 

[chirpy]

That is simply untrue. Firstly, you're only complaining about one part of suPHP which, there are other aspects that greatly improve server security. Secondly, If you want to prevent users from using their own php.ini files you can simply follow the recommendations in cPanel's own documentation and enable the global only php.ini files through /opt/suphp/etc/suphp.conf

 

[rustelekom]

untrue what? I can give you real server where unexperienced admins just don't know about this hole. They select suphp option and sure they are now safe - which is not true at all.

you can tell me that they need read manual etc. and i agree with you but fact is fact - in most times they just select option, compile php and that all. At least you need inform they about problem in settings.

Way which you offer to get suphp settings secured is correct but when we follow it we will lost great suphp feature - we cannot customize php settings per user basis.

Both option is bad - and it is not dilemma - go with security or with customizing, we already have third way and it give us both feature and without any compromise.

 

[brianoz]

I think you're confused; the fact that users can have php.ini files doesn't mean suphp is insecure, that's actually a feature.

With suphp you aren't as reliant on PHP features being locked down by the system php.ini. As users are effectively locked into their own home directories, it doesn't matter as much that they can change their php.ini files. A server with suphp is still an order of magnitude more secure than a server without it.

If you can provide a specific concrete example of how this was a problem in real life (other than users "not knowing about it") I'd be more than happy to discuss it and/or be proven wrong.

An important point to make is that suphp isn't instant perfect security - there is no such thing. While suphp helps a lot, it only improves security in a number of areas. Suphp is best coupled with other tools as part of an overall security strategy - such as the excellent mod_security and CSF firewall for starters.

BTW, if you run a high performance server with heavy hits, a good strategy is to restrict the users to highly trusted accounts and then you could remove suphp. But I'd always run suphp on a normal shared web server. High security = low maintenance = low costs of management.

 

[rustelekom]

"I think you're confused; the fact that users can have php.ini files doesn't mean suphp is insecure, that's actually a feature."

it is feature which should be controlled by sysadmin. Very simple example:

What you will do if customer edit his php.ini like shown below:

php_safe_mode = off;
disable_function = ;
open_base_directory = /;

Hah? Your server will open for hacking at least by using php. Customer can set timeouts as big as he want (and his php scripts never limited by your limits). You completely lost admin control on php settings etc. Am i need show you how such php settings may used for run phpshell or exploits?
Feature is nice but usage of this feature need to be controlled by system admin. Current situation is not right from all point of view. It make great suphp module as old phpsuexec which was is terrible for security.

And regards percentage of customizing. You are not correct with your mention about our settings.
You should understand that at least few common php settings used by scripts developers oppositely. For example directive mime_magic_quote_gpc. Some scripts work perfect with On value and some only work with Off value. Sometimes customer need bit a more memory limits than others, sometimes he need bit a more time to run their script. Do you like refuse customer only due to fact that you cannot change this very very simple setting? I think no.

 

[brianoz]

What you will do if customer edit his php.ini like shown below:

php_safe_mode = off;
disable_function = ;
open_base_directory = /;

Hah? Your server will open for hacking at least by using php.

Ah - I see, the source of your confusion

Just because they can change these settings does not leave your server open for hacking under suphp, whereas without suphp there would have been things they could see that they shouldn't have been able to see. In other words, relax, the impact just isn't there with suphp.

Customer can set timeouts as big as he want (and his php scripts never limited by your limits).

True, but I don't see this as such a big issue as a basic server check or CSF will show me long running processes.

You completely lost admin control on php settings etc. Am i need show you how such php settings may used for run phpshell or exploits?

Yes, but calm down a little they can't upload files unless there are other security issues; ie you have incredibly insecure scripts; and if you have those, the PHP settings should really be the least of your concerns as there will be other things they can do. Again, mod_security along with CSF is the best way to change these, not disabling PHP so tightly that every customer needs a different set of PHp settings!

And regards percentage of customizing. You are not correct with your mention about our settings.

Maybe I'm not right about your settings, but I'm right about mine. I'd say you have too many things locked down, making your PHP unusable.

You should understand that at least few common php settings used by scripts developers oppositely. For example directive mime_magic_quote_gpc. Some scripts work perfect with On value and some only work with Off value. Sometimes customer need bit a more memory limits than others, sometimes he need bit a more time to run their script. Do you like refuse customer only due to fact that you cannot change this very very simple setting? I think no.

Huh? I never said I'd refuse the customer the ability to change those things. I said they could change these things themselves. Easy. And if set up right, they rarely need to change them.

It's a matter of knowing where security matters, and where it doesn't, and I'm not convinced you've been able to make that distinction yet. I'm not meaning that in an unkind way, it simply takes time to get enough experience to understand what is important and what is not, and it helps if you know what "hacking" actually is. You're not being ignored; it's simply that your requests don't make logical sense and you haven't yet understood that.

In my opinion where you're focussing your energy isn't where you're going to get the greatest security benefit. PHP.ini settings won't protect you from many insecure scripts (although perhaps they could save you from some). Mod_security will save you from some, CSF will block people probing, and suphp will lock hackers into their own home dir and make it obvious who runs what scripts.

 

[UBERHOST]

untrue what? I can give you real server where unexperienced admins just don't know about this hole. They select suphp option and sure they are now safe - which is not true at all.

Inexperienced server administrators will always be a source of security holes. To blame it on suPHP would be like blaming airbags for accidents since they give inexperienced drivers a false sense of security.

 

[closet geek]

Both option is bad - and it is not dilemma - go with security or with customizing, we already have third way and it give us both feature and without any compromise.

So what is this third way?

 

[blargman]

suPHP is a good deal slower than DSO or fastcgi. I would recommend fastcgi over suphp if you want the scripts to run as the user. suPHP is ok for security but having php run as nobody in my opinion is better than giving it user level rights. There are other methods for securing php, mod_security/suhosin, disabling unneeded insecure functions.

Ideally someday I'd like to see something in the way of chroot'd apache configurations for each domain. This would offer the best security although may be a bit more performance heavy.

 

[brianoz]

I guess it depends on whether your priority is performance or security.

You'll never get as complete security at an application level - it's just bolted on. When you run as the user, there is no way around the file system permissions, there's no escaping that it's far more solid than a few checks in the application.

Having said that, if performance is critical it's probably because there are heavy load sites and it should be easy enough to move them off to a restricted box (ie a few heavy users) and run as DSO to get the performance. Though app design can help there's no escaping that CGI has to be far, far slower.

The problem with disabling unneeded functions is that they often end up being needed!

 

[brianoz]

suPHP is ok for security but having php run as nobody in my opinion is better than giving it user level rights.

I missed responding to this very intelligent and well made point which does make a lot of sense on the surface.

The problem with running PHP as nobody is, if the PHP (application level) restrictions are broached, the baddies have access to database usernames and passwords across all accounts on the server, which is earth shatteringly bad for security on that server. Application level protection will always be able to be broached on way or another by someone who is persistent enough or smart enough. The issue here is that "nobody" isn't actually a nobody here, it's an account that has access to all user application files on the server, and has to have that access by design!

Like anything it's a tradeoff; I'd guess it might be as much as an order of magnitude slower than pure DSO, and 2-5 times slower than fastcgi, and the figures could be worse! I dunno - I'd never run an open-access shared server without this level of security, I just see it as a minimum. If I need higher performance then I could move clients needing it to a DSO server.