I made the following changes to my config to improve security: /etc/conf.d/modules.d/70_mod_php.conf <IfModule !sapi_apache2.c> <Files ~ ".ph(p|tml|p3|p4|ps)"> Order allow,deny Deny from all </Files> </IfModule> This effectively stops any php code from being served up directly in case the php module is not loaded. I wanted to constribute this, since I think it would be good to have in the default install. (secure by default!).
(In reply to comment #0) > /etc/conf.d/modules.d/70_mod_php.conf > > <IfModule !sapi_apache2.c> > <Files ~ ".ph(p|tml|p3|p4|ps)"> > Order allow,deny > Deny from all > </Files> > </IfModule> This has already been extensively discussed in Bug 50611 (WONTFIX)... BTW, you shouldn't be denying access to .phps, that just doesn't make sense. ;)
And WONTFIX it will remain... Gentoo's policy is that things "should just work" (TM) on a default install, so always disabling all PHP files and then requiring the user to go change config files around is no viable solution, also on a correct, default install, mod_php will always be loaded (we fixed a little bug in the config-files just the other day, bug #122379), so there is really no need to disable this. Marking as WONTFIX is imo right here. Best regards, CHTEKK.
Re comment #1: I agree on still allowing .phps, that can be removed from the regex. However, I just reviewed 50611 and I have to say it looks like the concensus was in agreement with me. The last comment in that bug seems to indicate the solution is valid, but it should be applied to mod_php, not apache, which I agree with. That bug was assigned to the Apache herd, so that's why it was never resolved. Re comment #2: Regarding your comment about sensible defaults, I think you missed a subtle point, and that is, php files are only blocked if the php module is *not* loaded (IfModule !sapi_apache2c). So, by your reasoning the module _will_ always be loaded fine and the user won't be required to change any configs. Nothing is changed there. However, consider this scnenario. Install apache Install mod_php Install and configure mediawiki Everything is fine, system up and running. Down the road, apache is upgraded and during etc-update, /etc/conf.d/apache2 is accidently reverted to stock (no extra modules enabled). What happens now? Apache is restarted, and mod_php is not loaded. The site now proceeds to serve up .php source code directly. And in the case of MediaWiki, the database passwords are available to all (the bad design of mediawiki is besides the point). Wouldn't it be better instead of serving up those php source files, the web server then began refusing those requests? Either way the admin would quickly notice the problem. However, in this case there would be no security leaks. I'm leaving as RESOLVED, but please reconsider.
You're right, I didn't think of it in that light... Disabling the serving of .php* files (save for .phps) when mod_php is *not* loaded seems like a good and sensible idea, I'll see to fix the config files tomorrow to do this. Reopening so I won't forget. Best regards, CHTEKK.
Ok fixed versions of all the config files were just committed to CVS, emerge --sync in a couple of hours to get them. Now, if PHP{4|5} is defined (-D PHP{4|5} in /etc/conf.d/apache{2}), it tries first to load the module if it's not already loaded, then, if it's still not loaded it blocks access to all php files that that version of PHP would normally handle, otherwise, if the module is loaded and mod_mime is too, it sets the AddType's to make PHP interpret the php files it should. I hope this is ok, I think so, thanks for the ideas and the help! ;) Best regards, CHTEKK.
Ok. I just checked the version in portage. The config block I supplied should be moved to the bottom, outside the "IfDefine PHP4" block. We're not so much interested in whether the module is loaded, but whether it was indended to be loaded. Going back to my scenario posted earlier, if -DPHP4 is omitted from the config, the entire block is skipped and .php source files are still available in the clear. Also, if the LoadModule line is reached and the module doesn't load, apache will not start, so testing twice for the module is not necessary.
(In reply to comment #6) > The config block I supplied should be moved to the bottom, outside the > "IfDefine PHP4" block. No, we'll keep it inside, it's agreed that all additional modules have all their config in an IfDefine, since if you don't even enable -D PHP{4|5}, it's supposed you want your PHP files to be served as plaintext or some other way... Basically, if you don't have -D PHP{4|5}, you don't want PHP, or you really didn't understand anything of how Apache modules on Gentoo work and how to configure them, so case A is legit, case B is pebkac. :) > Also, if the LoadModule line is reached and the module doesn't load, apache > will not start, so testing twice for the module is not necessary. Hrmmm if it fails to start I fail to see why we need to block those files anyway? If it's loaded it works, if it's not loaded the LoadModule will make it fail, so we'll never reach a case where it's not loaded after the LoadModule, AND Apache has started... This would make those lines indeed obsolete... How it's now imo looks good and takes into consideration all cases, provided the IfDefine is ok, but I discussed that above. Best regards, CHTEKK.
> Basically, if you don't have -D PHP{4|5}, you don't want PHP, or you really > didn't understand anything of how Apache modules on Gentoo work and how to > configure them, so case A is legit, case B is pebkac. :) You should refer back to my example scenario, posted in comment #3. Yes, it is "PEBCAK" if the module is not correctly enabled, but the goal here is to limit it to an service outage, and not a security breach. If you really indend to serve .php files directly as plaintext, then you should either: A) not install mod_php B) rename them to .phps > Hrmmm if it fails to start I fail to see why we need to block those files > anyway? If it's loaded it works, if it's not loaded the LoadModule will make > it fail, so we'll never reach a case where it's not loaded after the > LoadModule, AND Apache has started... This would make those lines indeed > obsolete... You're right. Which is what I was saying, the additional IfModule checks after the LoadModule line are not necessary, they will only ever be evaluated if the module is loaded. > How it's now imo looks good and takes into consideration all cases, provided > the IfDefine is ok, but I discussed that above. As currently implemented, nothing is accomplished. The configuration behaves exactly as before, that is, php source code will be served up directly if the module is disabled. The "IfModule !sapi_apache2" check needs to be *after* the IfDefine check to work as intended. That is, if you install mod_php, but do not enable it, then the webserver will refuse to serve php source code uninterpreted. I cannot see any issue with this. I understand that module related-config should be inside IfDefine, but in this case, it's protection designed for the alternate case -- when the module is *not* loaded. So it's correct to always evaluate it when the php module is not loaded (whatever the reason).
We've discussed this and came to the conclusion that we won't put anything for PHP outside it's IfDefine, it's useless: you either have or not -D PHPX in your /etc/conf.d/apache{2} and you thus either want or not PHP enabled&parsed... The scenario where you just overwrite the conf.d/apache{2} file is really total pebkac, and should simply not happen in an enviroment where security of your installations, uptime or whatever is important. Since LoadModule takes care of killing Apache anyway if it can't load it, I'm going to delete those lines from the config files again, so we have: IfDef --> NotLoaded? Then Load it --> either it Loads it and goes further, or it dies. If the IfDef is not triggered, we assume you don't want PHP, as it's how modules in Gentoo are configured. Best regards, CHTEKK.
