ispCP - Board - Support
PHP-Security, geänderte php.ini - Printable Version

+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega International Area (/forum-22.html)
+--- Forum: German Corner (/forum-26.html)
+--- Thread: PHP-Security, geänderte php.ini (/thread-1652.html)

Pages: 1 2


PHP-Security, geänderte php.ini - jmeyerdo - 10-29-2007 07:50 PM

Hallo!

Nachdem bei mir "fastcgi" nun endlich läuft Smile, habe ich weitere Sicherheits-Tests durchgefürt.
Dabei ist mir aufgefallen (beim Testen mit "phpshell" - http://mgeisler.net/php-shell/), dass die Kommandos proc_open() und popen() nicht in der php.ini deaktiviert wurden.

Das Problem sehe ich darin, dass diese Funktionen scheinbar gesetzte "open_basedir"-Restriktionen ignorieren:
http://www.heise.de/newsticker/meldung/73837

Gibt es einen Grund dafür, dass diese nicht deaktiviert werden?
Falls nicht, würde ich vorschlagen, die unbedingt mit zu "disablen".

Eine zweite Frage:
FastCGI bietet ja das geniale Feature, für jeden User eine eigene php.ini verwenden zu können. So wäre ja theoretisch manuelles Finetuning für einzelne User möglich.
Allerdings ist mir aufgefallen, dass die User-php.ini bei jedem Update der Domain überschrieben wird. Ist das notwendig? Was für Einträge werden da ggf. bei einem Update generiert, die ein erneutes Kopieren notwendig machen?

Ansonsten würde ich vorschlagen, das Kopieren bei Updates zu unterlassen, damit manuelle Änderungen nicht verloren gehen.
Oder gibt es da sonst einen Workaround für dauerhafte, eigene Einträge?

Viele Grüße, Jens


RE: PHP-Security, geänderte php.ini - RatS - 10-29-2007 08:52 PM

proc_open sollte nur im Master aktiv sein. Müsste aber nachsehen.

Um Änderungen einzupflegen könntest du Includes verwenden. Muss dann nur einmal das Template anpassen.


RE: PHP-Security, geänderte php.ini - jmeyerdo - 10-29-2007 08:57 PM

Hi!
Danke für die schnelle Antwort...

Bei mir war das auch für den User freigeschaltet (aktueller Trunk von vor einigen Tagen).

Eine weitere php.ini inkludieren? An welcher Stelle wäre das möglich/sinnvoll?
Ist denn ein Überschreiben der php.ini bei jedem Update wirklich technisch notwendig?

Viele Grüße, Jens


RE: PHP-Security, geänderte php.ini - Zothos - 10-29-2007 11:22 PM

Wenn die funktionen nicht nur für den Master aktiviert sind, sondern auch für jeden normalen user, würde ich mal sagen das ist ein ticket wert.
Machst du eines auf jmeyerdo?


RE: PHP-Security, geänderte php.ini - jmeyerdo - 10-29-2007 11:30 PM

Ok, Ticket ist geöffnet.

Kann jemand überblicken, ob es technisch wirklich notwendig ist, die php.ini jedes Mal zu überschreiben?
Falls nicht, würde ich auch dafür ein Ticket öffnen.

VG, Jens


RE: PHP-Security, geänderte php.ini - monotek - 10-30-2007 12:33 AM

Imho ja, denn es wäre doch viel zu umständlich erst jede Datei auf manuelle Änderungen zu durchsuchen.

Wegen der Includes...
Ist das so wie bei Confiixx damals über die "HTTP Spezial" Einträge des Users möglich, die nur der Admin einstellen kann?
Wenn nicht, wäre das Imho noch ein nettes Feature für die Zukunft.


RE: PHP-Security, geänderte php.ini - jmeyerdo - 10-30-2007 12:40 AM

Hi!

Es ist klar, dass der vhost-Eintrag neu geschrieben werden muss. Im Moment sehe ich aber nicht, dass irgendwelche Änderungen einer Domain Auswirkungen auf die php.ini-Datei haben. Ist das richtig?
In diesem Fall wäre durch simples Verhindern des Überschreibens das Feature "angepasste php.ini möglich" drin...

VG, Jens


RE: PHP-Security, geänderte php.ini - RatS - 10-30-2007 01:24 AM

HTTP-Spezial ist nichts anderes, als php_admin_values, aber die funktionieren nur mit mod_php.


RE: PHP-Security, geänderte php.ini - jmeyerdo - 10-30-2007 01:34 AM

Hi RatS!

Ja richtig - und diese werden nicht in der php.ini, sondern in der .conf für die VHosts gesetzt.

Du bist doch einer der Profis, die mir meine Frage beantworten können, oder? Wink Werden tatsächlich bei einem Domainupdate Änderungen in der php.ini notwendig?

VG, Jens


RE: PHP-Security, geänderte php.ini - Zothos - 10-30-2007 03:14 AM

OT: Man könnte auch mod_security verwenden und auf vhost basis das php befehle deaktivieren.