PHP Security Tweaks

[Jeffrey Tadlock]

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

[1] http://www.hardened-php.net/suhosin.127.html