Bietet die Verwendung von chroot für einen öffentlich zugänglichen Dienst einen echten Sicherheitsvorteil?

Bietet die Verwendung von chroot für einen öffentlich zugänglichen Dienst einen echten Sicherheitsvorteil?

Ich hätte gern eine definitive Antwort darauf, warum diese Vorgehensweise bei Diensten angewendet werden sollte, die potenziell feindlichen Netzwerken (z. B. dem Internet) ausgesetzt sind. So wie ich es verstehe, gibt es eine Methode, um aus einem Chroot-Jail auszubrechen. Wenn diese Sicherheitsmaßnahme also keinen echten Wert hat, warum wird sie dann in einigen Installationen immer noch angewendet?

Antwort1

Sie sollten ein Chroot niemals als vollständige Sicherheitsfunktion betrachten. Es erschwert zwar Angriffe, aber wenn Sie es schaffen, innerhalb des Chroots etwas Kontrolle zu erlangen, ist es ziemlich einfach, daraus auszubrechen. Es gibt eine Methode, bei der das Chrooting in ein übergeordnetes Verzeichnis erfolgt (..) Weitere InformationenHier. Der Grund, warum Chroot einen gewissen Sicherheitsvorteil bietet, ist, dass viele der Anwendungen, die ein Hacker erwarten würde, einfach nicht vorhanden sind. Wenn ich die Wahl zwischen Chroot und Nicht-Chroot hätte, würde ich die Chroot-Option wählen.

Ein besserer Ansatz wäre so etwas wie BSDs Jail, Solaris' Zonen oder eine Virtualisierungstechnologie wie KVM oder Xen. Diese Ansätze nutzen dieselbe Idee der Kompartimentierung wie Chroot und machen sie dadurch stärker. Sie könnten sich auch etwas wie SELinux ansehen, aber das ist etwas komplizierter und daher fehleranfälliger.

Antwort2

So wie ich es verstehe, gibt es eine Methode, um aus einem Chroot-Jail auszubrechen (...), warum versuchen es dann einige Installationen immer noch damit?

Dasselbe gilt für Passwörter. Der Punkt ist, dass man Eindringlingen oft so viele Hindernisse in den Weg legt, dass sie aufgeben müssen, bevor sie ihr Ziel erreichen. Sie können sich nicht auf eine einzige Methode verlassen, um eine bestimmte Ressource zu sichern. Darüber hinaus gibt Ihnen Chrooting mehr Kontrolle über eine Anwendung, die Sie ausführen. Sie können den Zugriff dieser Anwendung auf Dateisystemressourcen einschränken.

Antwort3

Ja tut es.

  • Wenn Ihr Daemon oder was auch immer den Dienst bereitstellt, nicht als Root ausgeführt wird, ist sogar eine Lücke in diesem Daemon vom Rest des Systems isoliert.
  • Wenn Ihr Betriebssystem die Operationen einschränken kann, die während des Chroot-Zugriffs ausgeführt werden können, ist das sogar noch besser. Grsec-Patches für Linux können beispielsweise dem Root-Benutzer innerhalb eines Chroots die Möglichkeit nehmen, auszubrechen oder /dev-Knoten innerhalb des Chroots zu erstellen.

Wenn Sie jedoch einen ausnutzbaren Kernel-Fehler (oder einfach nur ein Root-Loch, wenn es sich nicht um Grsec- oder BSD-Jails handelt) innerhalb des Chroots haben, dann ist das ganze System im Besitz des Angreifers. Nicht so, wenn Sie einen echten Virtualisierer (wie VMWare, aber KEINE BSD-Jails) ausführen. Diese helfen nicht, da sie für alle „Systeme“ denselben Kernel verwenden.

Also ja, es fügt eine Sicherheitsebene hinzu, wenn es richtig verwendet wird.

Antwort4

Ich finde Chroots viel zu kompliziert und habe es noch nie geschafft, eines zu installieren. Man könnte argumentieren, dass ich großes Interesse daran hätte, wenn ich dazu in der Lage gewesen wäre, aber das habe ich bisher nicht getan.

Ich denke, dass es angesichts der heute verfügbaren Rechenleistung eine viel bessere Idee ist, Ihre Dienste in virtuellen Maschinen zu isolieren (natürlich auf Xen, aber VMWare funktioniert auch, wenn Sie darauf bestehen :-P). Virtuelle Maschinen haben außerdem den großen Vorteil, dass sie sehr einfach zu sichern/migrieren sind, was bei Chroots nicht der Fall ist. Sie haben außerdem eine umfassende Schnittstelle zur Verwaltung von VMs, die bei Chroots definitiv nicht vorhanden ist.

verwandte Informationen