um Deine Frage beantworten zu können, wäre es hilfreich zu wissen, was Du Dir davon versprichst, die verschiedenen Dienste in chroot-Umgebungen zu stecken, und was für ein Setup Dir genau vorschwebt (bzw. was Du bereits benutzt). IMHO kann es dafür zwei Hauptgründe geben:
Zum einen schlicht und ergreifend Organisation: Da Linux eine simple OS-Level Virtualisierung fehlt, kann man Chroot-Umgebungen verwenden, um komplett konfigurierte lauffähige Umgebungen (auch verschiedener Distributionen) bequem nebeneinander auf einer Maschine zu betreiben oder sie von einer Maschine auf die nächste verschieben zu können - oder bestimmte Dienste mehrfach auf einem System laufen zu lassen, die sich sonst ggf. in die Quere kommen würden. Das ganze lässt sich noch beliebig ausschmücken, LVM wäre hier ein weiteres Stichwort.
Der andere Grund, der häufig angeführt wird, sind Sicherheitserwägungen. Dazu muss man aber wissen, dass der chroot-Syscall ursprünglich nicht zu diesem Zweck implementiert wurde. Der chroot-Syscall setzt für einen Prozess ein bestimmtes Verzeichnis als neues root level directory. Somit sind die übrigen Bestandteile des Verzeichnisbaums für diesen Prozess nicht mehr sichtbar, was zunächst schon einen gewissen Schutz darstellt. Allerdings bleibt es dem Prozess weiterhin gestattet, beliebige Syscalls an den Kernel abzusetzen. Mit einer einfachen Kombination aus chdir() und chroot() ist der Prozess auch schon wieder schwuppdiwupp aus der chroot-Umgebung "ausgebrochen".
Um an einem Beispiel zu verdeutlichen, was ich damit meine: Angenommen, Du betreibst in einer chroot-Umgebung Apache mit mod_php. Nehmen wir weiter an, ein fieser Angreifer sei in der Lage, eine laufende PHP-Anwendung zu kompromittieren und PHP dazu zu bringen, eine Remote Shell auszuführen. Dies wäre dann ein Kindprozess des Apache Webservers, der alle Eigenschaften (unter anderem den root directory context) von seinem Elternprozess geerbt hat. Stellt der Angreifer nun fest, dass er innerhalb einer chroot-Umgebung eingesperrt ist (z. B. fehlende Verzeichnisse und/oder Dateien, die in einer "echten" Installation vorhanden wären), könnte er mit chdir() und chroot() dafür sorgen, dass sich der root directory context seiner Shell wieder auf das "echte" / ändert - er wäre also ausgebrochen.
Es gibt aber Möglichkeiten, einen solchen Ausbruchsversuch zu erschweren bzw. unmöglich zu machen. Die Rede ist dabei von Kernel-Patches, die es sich zur Aufgabe gemacht haben, die Standard-Implementierung bestimmter SysCalls durch "gehärtete" Fassungen zu ersetzen. Die beiden bekanntesten Projekte sind grsecurity und RSBAC. Ersteres habe ich selbst seit einigen Jahren im Einsatz (was nicht heißen soll, das RSBAC schlechter ist - im Gegegenteil, es geht bei vielen Dingen noch deutlich weiter als grsecurity, allerdings ist es auch wesentlich komplexer zu konfigurieren). Beide verändern den Kernel so, dass vor der Ausführung eines SysCalls immer geprüft wird, welchen root level context ein Prozess hat. Entspricht dieser nicht dem "echten" /, darf der Prozess z. B. kein chdir() oder chroot() aufrufen; auch andere Syscalls werden gesperrt. Darüber hinaus bieten beide Patches noch viele weitere Sicherheitsverbesserungen, deren Aufzählung hier allerdings den Rahmen sprengen würde.
Wenn Du also chroot aus Sicherheitsgründen verwenden möchtest, solltest Du auf jeden Fall den Einsatz eines gehärteten Kernels in Erwägung ziehen. Außerdem gilt dann auch: weniger ist mehr, also wirklich nur die Bibliotheken und Binaries in die chroot-Umgebung kopieren, die der einzusperrende Dienst zum laufen benötigt - die debootstrap-Methode würde deutlich mehr installieren, was eben zu einem gewissen Grad das Risiko erhöht. Bei einer manuell erstellten chroot-Umgebung kannst Du dann auch auf den Einsatz von mod_chroot verzichten - der Apache "weiß" dann gar nicht erst, dass er eingesperrt wurde.
Wenn Du nun (aus welchen Erwägungen heraus auch immer) Apache und MySQL in chroot-Umgebungen stecken willst, müssen Dir noch folgende Dinge klar sein:
- Wenn Du mod_php einsetzt, läuft PHP automatisch im selben Kontext wie Apache, da mit mod_php jeder Apache-Prozess selbst die Fähigkeit erhält, PHP-Skripte zu interpretieren, womit keine externen Prozesse mehr erzeugt werden müssen
- Wenn Apache (bzw. PHP) und MySQL in jeweils unterschiedlichen chroot-Umgebungen stecken, ist die Kommunikation zwischen beiden nicht mehr über Unix Sockets möglich ("localhost"), sondern nur noch über TCP ("127.0.0.1"). Eine Möglichkeit wäre das sezten eines Hardlinks innerhalb des Apache-chroot auf den MySQL-Socket, aber das geht nur, wenn beide auf derselben Partition liegen.
- Besonders interessant wäre es, Apache und PHP mit unterschiedlichem Kontext laufen zu lassen (z. B. Apache in /var/www, PHP-Prozesse des einen virtuellen Hosts in /var/www/user1 und die des nächsten in /var/www/user2 etc.). Das funktioniert aber nur mit FastCGI, da (zumindest bei einem gehärteten Kernel) vom Apache erzeugte Prozesse nicht noch einmal den Kontext wechseln dürfen, womit CGI und suPHP ausscheiden (bei mod_php ist es ohnehin nicht möglich).
- Gegen bestimmte Angriffsformen bietet chroot() keine zusätzliche Sicherheit, ob gehärtet oder nicht. Hat es ein Angreifer nur darauf abgesehen, Deine Website zu verwüsten (Defacing), muss er dazu aus der chroot-Umgebung gar nicht ausbrechen. Während eine defaced Website noch durch zurückspielen eines Backups leicht behoben ist, sieht es bei einer anderen Angriffsform schon deutlich schwieriger aus: Die Rede ist von Spammern, die Deinen Server zum Versand ihres Dosenfleischs nutzen wollen. Auch für sie besteht keine Notwendigkeit, aus einer chroot-Umgebung auszubrechen, solange sie einen Prozess kontrollieren, der per TCP mit dem MTA kommunizieren darf (TCP-Verbindungen aus chroot-Umgebungen lassen sich nur mit RSBAC einschränken => Stichwort Jail) - 127.0.0.1 wird von den meisten Mailservern als vertrauenswürdige Quelle erachtet, für die keine Authentifizierung verlangt wird.
) der Ausbruch gelingt - allerdings muss er dazu das Jail gründlich von innen analysieren, möglicherweise mehrfach einbrechen oder sich sogar eine Hintertür offen lassen. Das sind alles Dinge, die man mit den richtigen Werkzeugen auch rechtzeitig bemerken kann, und zwar von außerhalb des Jails. Mit Werkzeugen (am Ende also Prozessen), die der Angreifer nicht wahrnehmen und beeinflussen kann, solange er noch nicht aus dem Jail ausgebrochen ist. Security Event Auditing (auditd unter FreeBSD, BSM unter Solaris) gekoppelt mit einer entsprechenden Warnmeldekette wäre hier wohl das Mittel der Wahl.