Technik

Vor ein paar Jahren hatte ich schon einmal versucht PHP-Prozesse auf dem Webserver in ein chroot()-Jail zu stecken. Auch wenn ich seinerzeit ein paar Erfolge verzeichnet hatte, haben es meine damaligen Bemühungen nie in den Produktions-Betrieb geschafft - der Gedanke daran jedoch blieb.

Aus heutiger Sicht weiß ich gar nicht mehr, was ich seinerzeit alles angestellt habe, es war auf jeden Fall kompliziert. Wenn man den Punkt ein Jail zu bauen, dass alle notwendigen Anwendungen und Bibliotheken enthält, außen vor lässt hat man - wie im Titel bereits erwähnt - immer noch 4 Komponenten, die miteinander arbeiten müssen. Am wichtigsten hier ist, dass das was am Anfang in der Kette eingegeben wird am anderen Ende einen gültigen Wert besitzt. In einem "normalen" Setup ist das stets gegeben, in einer chroot()-Umgebung ist eine der wichtigsten Eigenschaften - der Pfad zur Skript-Datei, die ausgeführt werden soll - falsch. Was also tun?

Fangen wir mal am Anfang an: Der Webserver (httpd) nimmt eine HTTP-Anfrage entgegen, mod_fcgid fühlt sich für diese verantwortlich und startet (bei Bedarf) mittels SuExec einen PHP-FastCGI-Server.
Der einzige Teilnehmer in dieser Kette, der aktiv "weiß" dass ein chroot()-Jail existiert, ist SuExec, denn an diesem Punkt wird es auch initiiert. Bei einer einfachen CGI-Anwendung könnte SuExec auch die Umgebungs-Variablen umschreiben, bei FastCGI hingegen wird SuExec einmal ausgeführt und kann für "beliebig viele" Anfragen verwendet werden. Maßgeblich ist dabei nur die User-/Group-ID unter der der Skript ausgeführt wird, die Pfade hingegen können vollkommen verschieden sein (z.B. wenn mehrere Domains vom selben Benutzer verarbeitet werden).
Als Konsequenz hieraus müssen nun im FastCGI-Server (PHP) ein paar Anpassungen vorgenommen werden, denn PHP wird immer die vollen Pfade von außerhalb des chroot()s mitbekommen und wird damit nichts anzufangen wissen.

Als einfachste und naivste Lösung könnte man im neuen Root (sei es /home/chroot) einen gleich lautenden Link auf sich selbst erzeugen  (/home/chroot/home/chroot -> ../../). Das ist aber sehr dreckig und ich würde es als Methode für ein Produktiv-System nicht  zulassen.

Eine bessere Lösung bietet PHP selbst mit seiner doc_root-Direktive in der php.ini: Wird vom Webserver die Umgebungsvariable DOCUMENT_ROOT nicht übertragen, wird dieser Wert beim Suchen von Skripten zur Rate gezogen. Bis PHP 5.3 eigentlich auch nicht nutzbar, da der Wert nur global zu definieren war. Mit Einführung der konditionalen Sektionen in der php.ini ist dieses Feature jedoch recht brauchbar geworden. Allerdings muss man hier jede Domain bzw. jeden Pfad in einer weiteren Datei (der php.ini) konfigurieren - ein weiterer Punkt, wo sich Fehler einschleichen können - besonders wenn man plant, die php.ini komplett in fremde Hände zu geben.

Die für mich sinnvollste Variante war aber eher etwas mehr "Bewusstsein" für die chroot()-Umgebung in PHP zu wecken. Hierzu muss man PHP von außen einen Tipp geben, wo es sich befindet - am einfachsten über eine neue Umgebungsvariable, die in SuExec gesetzt und von PHP beim Finden der Skript-Datei genutzt wird. Der FastCGI-Server lässt diese Variablen auch zwischen den Anfragen intakt, sodass sie bis zum Ableben des Servers erhalten bleiben. Wir schreiben in diese Variable einfach vor dem Aufruf von chroot(), wohin diese Anfrage geht und gleichen sie in PHP dann mit den Variablen SCRIPT_FILENAME und DOCUMENT_ROOT ab. Bei Bedarf werden letztere Beschnitten und gut ists - für die ausgeführten PHP-Skripte sieht es nach einer ganz normalen Umgebung aus.

Kombiniert man das mit einem FTP-Server und einem SSH-Server (mit SCP, SFTP und RSync) die beide nach dem selben Schema chroot()s aufbauen wird es eine runde Sache. Ich freue mich!