I asked yesterday in the meeting about any modifications made to the default PHP install to help tighten things up a little with MediaWiki quite close to going into production. I took a look at the php.ini file on publictest2 and have a couple of suggestions to make - please feel free to comment or question any of them. I will add my own comments after each item.
/etc/php.ini
* Change 'allow_url_fopen' to Off.
This is a big one as it can allow a remote file to be used in an include().
* Set 'expose_php' to Off.
This one is just to reduce the amount of information one can gather through a script looking for vulnerable versions. Anyone determined to cause trouble could determine this information another way, like the Version info page in MediaWiki.
* Set 'display_errors' to Off
I think this was just set to On in testing to help with working through various bugs. But we should be sure it is set to Off for the production instance.
* Set the upload_tmp_dir to a location that is only accessible by the user running MediaWiki and not readable or writeable by anyone else as well as being outside the web root.
* Use disable_functions to limit what PHP functions are available. The following is a possible recommended list:
disable_functions = "apache_get_modules,apache_get_version,apache_getenv,apache_note, apache_setenv,disk_free_space,diskfreespace,dl,
highlight_file,ini_alter,ini_restore,openlog,passthru,phpinfo,
proc_nice,shell_exec,show_source,symlink,system,exec,fsockopen, dl,popen"
This appears to work on a MediaWiki instance I have, though that wiki is not as large or complex as the Fedora Wiki will be. Some of the items above are just information gathering components, others have a little more value to them.
And then, set an open_base_dir directive in the wiki.conf file like this:
php_admin_value open_basedir /var/www/wiki:/location/of/upload/tmp/dir
Setting an open_basedir is not 100% foolproof to limiting access to PHP scripts, but it is another hurdle.
The above config changes are some options we might want to consider. There are also tools out there like php-suhosin [1] that we might want to consider using as well to keep things as tight as possible. I have not made any changes to publictest2, but we may want to consider trying some of these config changes out and see if things still work and then possibly apply to the production instance.
Thanks! Jeffrey
On Fri, 23 May 2008, Jeffrey Tadlock wrote:
I asked yesterday in the meeting about any modifications made to the default PHP install to help tighten things up a little with MediaWiki quite close to going into production. I took a look at the php.ini file on publictest2 and have a couple of suggestions to make - please feel free to comment or question any of them. I will add my own comments after each item.
/etc/php.ini
- Change 'allow_url_fopen' to Off.
This is a big one as it can allow a remote file to be used in an include().
- Set 'expose_php' to Off.
This one is just to reduce the amount of information one can gather through a script looking for vulnerable versions. Anyone determined to cause trouble could determine this information another way, like the Version info page in MediaWiki.
- Set 'display_errors' to Off
I think this was just set to On in testing to help with working through various bugs. But we should be sure it is set to Off for the production instance.
- Set the upload_tmp_dir to a location that is only accessible by the
user running MediaWiki and not readable or writeable by anyone else as well as being outside the web root.
- Use disable_functions to limit what PHP functions are available.
The following is a possible recommended list:
disable_functions = "apache_get_modules,apache_get_version,apache_getenv,apache_note, apache_setenv,disk_free_space,diskfreespace,dl,
highlight_file,ini_alter,ini_restore,openlog,passthru,phpinfo,
proc_nice,shell_exec,show_source,symlink,system,exec,fsockopen, dl,popen"
This appears to work on a MediaWiki instance I have, though that wiki is not as large or complex as the Fedora Wiki will be. Some of the items above are just information gathering components, others have a little more value to them.
And then, set an open_base_dir directive in the wiki.conf file like this:
php_admin_value open_basedir /var/www/wiki:/location/of/upload/tmp/dir
Setting an open_basedir is not 100% foolproof to limiting access to PHP scripts, but it is another hurdle.
The above config changes are some options we might want to consider. There are also tools out there like php-suhosin [1] that we might want to consider using as well to keep things as tight as possible. I have not made any changes to publictest2, but we may want to consider trying some of these config changes out and see if things still work and then possibly apply to the production instance.
Thanks! Jeffrey
These are all fine with me.
-Mike
On Fri, May 23, 2008 at 9:08 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Fri, 23 May 2008, Jeffrey Tadlock wrote:
Change 'allow_url_fopen' to Off.
Set 'expose_php' to Off.
Set 'display_errors' to Off
Set the upload_tmp_dir to a location that is only accessible by the
user running MediaWiki and not readable or writeable by anyone else as well as being outside the web root.
disable_functions = "apache_get_modules,apache_get_version,apache_getenv,apache_note, apache_setenv,disk_free_space,diskfreespace,dl,
highlight_file,ini_alter,ini_restore,openlog,passthru,phpinfo,
proc_nice,shell_exec,show_source,symlink,system,exec,fsockopen, dl,popen"
php_admin_value open_basedir /var/www/wiki:/location/of/upload/tmp/dir
These are all fine with me.
I made most of these changes tonight on publictest2. There were two exceptions.
I did not change the 'display_errors' as it is useful for the testing going on.
'open_basedir' is causing issues with the user's page (i.e. clicking the jeffreyt link at the top of the page), when it is enabled it just goes to a blank page. The same happens with the Infrastructure page as well. Everything else seemed to work well with it enabled. I will play with that on a vanilla install at home and see what is up with that.
Everything else has been modified.
If something has broken and I missed it, feel free to ping me (iWolf) on IRC. If I am not around you can grab the original php.ini file from my home directory under the php-sec directory. Just copy it to /etc/php.ini and bounce apache and you will be back to the way it was before I made the changes. Please let me know if you need to do that though, so I can look at it further.
Thanks, Jeffrey
On Sat, May 24, 2008 at 10:18 PM, Jeffrey Tadlock linux@elfshadow.net wrote:
'open_basedir' is causing issues with the user's page (i.e. clicking the jeffreyt link at the top of the page), when it is enabled it just goes to a blank page. The same happens with the Infrastructure page as well. Everything else seemed to work well with it enabled. I will play with that on a vanilla install at home and see what is up with that.
I think I have this working now. I needed to add /usr/share/pear to the open_basedir list. The things I saw broken because of that last night now appear to be working. It is now enabled on publictest2.
If I am not around and it turns out it is causing issues somewhere else, you can just comment it out in /etc/php.ini and bounce Apache and you'll be good to go.
If something has broken and I missed it, feel free to ping me (iWolf) on IRC. If I am not around you can grab the original php.ini file from my home directory under the php-sec directory. Just copy it to /etc/php.ini and bounce apache and you will be back to the way it was before I made the changes. Please let me know if you need to do that though, so I can look at it further.
Same applies. I have some garden work to do this afternoon, so if I am not around, you can copy the original php.ini from my home directory under the php-sec directory to /etc/php.ini and bounce apache to be back to the original way it was before I made changes. Just let me know if you end up needing to do that so I can look at it further.
Thanks! Jeffrey
On Sun, 25 May 2008, Jeffrey Tadlock wrote:
On Sat, May 24, 2008 at 10:18 PM, Jeffrey Tadlock linux@elfshadow.net wrote:
'open_basedir' is causing issues with the user's page (i.e. clicking the jeffreyt link at the top of the page), when it is enabled it just goes to a blank page. The same happens with the Infrastructure page as well. Everything else seemed to work well with it enabled. I will play with that on a vanilla install at home and see what is up with that.
I think I have this working now. I needed to add /usr/share/pear to the open_basedir list. The things I saw broken because of that last night now appear to be working. It is now enabled on publictest2.
If I am not around and it turns out it is causing issues somewhere else, you can just comment it out in /etc/php.ini and bounce Apache and you'll be good to go.
If something has broken and I missed it, feel free to ping me (iWolf) on IRC. If I am not around you can grab the original php.ini file from my home directory under the php-sec directory. Just copy it to /etc/php.ini and bounce apache and you will be back to the way it was before I made the changes. Please let me know if you need to do that though, so I can look at it further.
Same applies. I have some garden work to do this afternoon, so if I am not around, you can copy the original php.ini from my home directory under the php-sec directory to /etc/php.ini and bounce apache to be back to the original way it was before I made changes. Just let me know if you end up needing to do that so I can look at it further.
Thanks for looking in to this stuff, once we're sure its all working right we can get that in to puppet and deploy it on our new mediawiki hosts.
-Mike
On Sun, 25 May 2008, Jeffrey Tadlock wrote:
On Sat, May 24, 2008 at 10:18 PM, Jeffrey Tadlock linux@elfshadow.net wrote:
'open_basedir' is causing issues with the user's page (i.e. clicking the jeffreyt link at the top of the page), when it is enabled it just goes to a blank page. The same happens with the Infrastructure page as well. Everything else seemed to work well with it enabled. I will play with that on a vanilla install at home and see what is up with that.
I think I have this working now. I needed to add /usr/share/pear to the open_basedir list. The things I saw broken because of that last night now appear to be working. It is now enabled on publictest2.
Side note about this, it seems to have broken OpenID support. I've reverted to a default configuration so ricky can continue testing. If you've got a moment could you hook up with him at some point and find out exactly what configuration is causing the problem?
-Mike
On Sun, May 25, 2008 at 11:40 PM, Mike McGrath mmcgrath@redhat.com wrote:
Side note about this, it seems to have broken OpenID support. I've reverted to a default configuration so ricky can continue testing. If you've got a moment could you hook up with him at some point and find out exactly what configuration is causing the problem?
I checked the file listing in the OpenID packages and I bet the open_basedir wasn't letting the OpenID stuff have access to the files it needed. I can modify that and allow access to those directories it most likely needs.
It's a trip to the zoo day with the kids, but I will cross paths with Ricky later today/this evening and get this sorted out.
Thanks! Jeffrey
I took a look at pt2 again today and it looks like the php.ini was set back to the default after Ricky and I sorted out the OpenID issues on Monday.
Was the more restrictive version causing troubles for someone? I would be happy to look at what was going on - so far we've been able to adjust it to make everything that has been brought to my attention work - but I need to know what broke to see what needs tweaked before rolling this to the production systems.
Just let me know what broke and I will look at it again.
Thanks! Jeffrey
On Sat, 31 May 2008, Jeffrey Tadlock wrote:
I took a look at pt2 again today and it looks like the php.ini was set back to the default after Ricky and I sorted out the OpenID issues on Monday.
Was the more restrictive version causing troubles for someone? I would be happy to look at what was going on - so far we've been able to adjust it to make everything that has been brought to my attention work - but I need to know what broke to see what needs tweaked before rolling this to the production systems.
Just let me know what broke and I will look at it again.
Sorry, I'll set that back to how it was. I moved it to test some strange things that were happening.
-Mike
On Sat, May 31, 2008 at 11:30 AM, Mike McGrath mmcgrath@redhat.com wrote:
Sorry, I'll set that back to how it was. I moved it to test some strange things that were happening.
Cool! Thanks Mike. I wasn't sure if it had caused issues again or not. I was giving it some time to sit on publictest2 without causing issues before seeing if we could push it to production.
Thanks! Jeffrey
On Sat, 31 May 2008, Jeffrey Tadlock wrote:
On Sat, May 31, 2008 at 11:30 AM, Mike McGrath mmcgrath@redhat.com wrote:
Sorry, I'll set that back to how it was. I moved it to test some strange things that were happening.
Cool! Thanks Mike. I wasn't sure if it had caused issues again or not. I was giving it some time to sit on publictest2 without causing issues before seeing if we could push it to production.
nope, we should give it another good lookover on pt2 though and decide when we want to move it.
-Mike
infrastructure@lists.fedoraproject.org
-
Jeffrey Tadlock -
Mike McGrath