Wie führt man Chroot mit Linux-Namespaces durch?

Andere Verwendungen [von Namespaces] umfassen […] die Isolation eines Prozesses im Stil von chroot() auf einen Teil der einzelnen Verzeichnishierarchie.

Wenn ich jedoch den Mount-Namespace klonen, beispielsweise mit dem folgenden Befehl, sehe ich immer noch den gesamten ursprünglichen Stammbaum.

unshare --mount -- /bin/bash

Ich verstehe, dass ich jetzt in der Lage bin, zusätzliche Mounts im neuen Namespace durchzuführen, die nicht mit dem ursprünglichen Namespace geteilt werden, und somit bietet dies Isolation, aber es ist immer noch derselbe Stamm, z. /etc ist immer noch für beide Namensräume gleich. Brauche ich noch chroot Root ändern oder gibt es eine Alternative?

Ich hatte erwartet, dass diese Frage eine Antwort liefern würde, aber die Antwort verwendet nur chroot , wieder.

EDIT #1

Es gab einen jetzt gelöschten Kommentar, der pivot_root erwähnte . Da dies eigentlich Teil von linux/fs/namespace.c ist , es ist tatsächlich Teil der Namensraumimplementierung. Dies legt nahe, das Root-Verzeichnis nur mit unshare zu ändern und mount ist nicht möglich, aber Namespaces bietet eine eigene – cleverere – Version von chroot . Trotzdem verstehe ich nicht die Hauptidee dieses Ansatzes, der ihn grundlegend von chroot unterscheidet , auch nach dem Lesen des Quellcodes (im Sinne von z. B. Sicherheit oder besserer Isolation).

BEARBEITUNG Nr. 2

Dies ist kein Duplikat dieser Frage. Nachdem ich alle Befehle aus der Antwort ausgeführt habe, habe ich ein separates /tmp/tmp.vyM9IwnKuY (oder ähnliches), aber das Stammverzeichnis ist immer noch dasselbe!

Akzeptierte Antwort:

Eingabe eines Mount-Namensraums vor dem Einrichten einer chroot , können Sie vermeiden, den Host-Namespace mit zusätzlichen Mounts zu überladen, z. für /proc . Sie können chroot verwenden innerhalb eines Mount-Namespace als netter und einfacher Hack.

Ich denke, es hat Vorteile, pivot_root zu verstehen , aber es hat eine gewisse Lernkurve. Die Dokumentation erklärt nicht alles… obwohl es ein Anwendungsbeispiel in man 8 pivot_root gibt (für den Shell-Befehl). man 2 pivot_root (für den Systemaufruf) könnte klarer sein, wenn es dasselbe tun würde und ein Beispiel-C-Programm enthalten würde.

Wie man pivot_root verwendet

Unmittelbar nach der Eingabe des Mount-Namensraums benötigen Sie auch mount --make-rslave / oder gleichwertig. Andernfalls werden alle Ihre Mount-Änderungen an die Mounts im ursprünglichen Namespace weitergegeben, einschließlich pivot_root . Das willst du nicht :).

Wenn Sie unshare --mount verwendet haben Beachten Sie, dass die Anwendung von mount --make-rprivate dokumentiert ist standardmäßig. AFAICS ist dies ein schlechter Standard und Sie möchten dies nicht im Produktionscode. Z.B. An diesem Punkt würde es eject stoppen daran gehindert, an einer gemounteten DVD oder einem USB-Stick im Host-Namespace zu arbeiten. Die DVD oder der USB-Stick blieben im privaten Mount-Baum gemountet, und der Kernel ließ Sie die DVD nicht auswerfen.

Sobald Sie das getan haben, können Sie z.B. der /proc Verzeichnis, das Sie verwenden werden. Genauso wie für chroot .

Anders als wenn Sie chroot verwenden , pivot_root erfordert, dass Ihr neues Root-Dateisystem ein Einhängepunkt ist. Wenn dies noch nicht der Fall ist, können Sie dies erfüllen, indem Sie einfach ein Bind-Mount anwenden:mount --rbind new_root new_root .

Verwenden Sie pivot_root – und dann umount das alte Root-Dateisystem mit dem -l / MNT_DETACH Möglichkeit. (Sie brauchen umount -R nicht , was länger dauern kann.).

Technisch gesehen wird pivot_root verwendet muss im Allgemeinen die Verwendung von chroot umfassen auch; es ist kein „entweder-oder“.

Gemäß man 2 pivot_root , ist es nur als Austausch des Stammverzeichnisses des Mount-Namespace definiert. Es ist nicht definiert, zu ändern, auf welches physische Verzeichnis der Prozessstamm verweist. Oder das aktuelle Arbeitsverzeichnis (/proc/self/cwd ). Es kommt vor, dass es das tut tun, aber dies ist ein Hack, um Kernel-Threads zu handhaben. Laut Manpage könnte sich das in Zukunft ändern.

Normalerweise möchten Sie diese Sequenz:

chdir(new_root);            // cd new_root
pivot_root(".", put_old);   // pivot_root . put_old
chroot(".");                // chroot .

Die Position von chroot in dieser Sequenz ist noch ein weiteres subtiles Detail. Obwohl der Punkt pivot_root ist, den Mount-Namensraum neu anzuordnen, scheint der Kernel-Code das zu verschiebende Root-Dateisystem zu finden, indem er sich das Pro-Prozess-Root ansieht, was chroot ist Sätze.

Warum sie pivot_root verwenden sollten

Grundsätzlich ist es sinnvoll, pivot_root zu verwenden für Sicherheit und Isolation. Ich denke gerne über die Theorie der fähigkeitsbasierten Sicherheit nach. Sie übergeben eine Liste der spezifischen Ressourcen, die benötigt werden, und der Prozess kann auf keine anderen Ressourcen zugreifen. In diesem Fall sprechen wir über die Dateisysteme, die an einen Mount-Namespace übergeben werden. Diese Idee gilt im Allgemeinen für die Linux-Funktion „Namespaces“, obwohl ich sie wahrscheinlich nicht sehr gut ausdrücke.

chroot legt nur den Prozessstamm fest, aber der Prozess verweist immer noch auf den vollständigen Mount-Namespace. Wenn ein Prozess das Privileg behält, chroot auszuführen , dann kann es den Dateisystem-Namespace sichern. Wie in man 2 chroot beschrieben , „der Superuser kann aus einem ‚Chroot-Gefängnis‘ entkommen, indem er …“.

Ein weiterer zum Nachdenken anregender Weg, um chroot rückgängig zu machen ist nsenter --mount=/proc/self/ns/mnt . Dies ist vielleicht ein stärkeres Argument für das Prinzip. nsenter / setns() lädt zwangsläufig das Prozessstammverzeichnis aus dem Stammverzeichnis des Mount-Namensraums neu … obwohl die Tatsache, dass dies funktioniert, wenn die beiden auf unterschiedliche physische Verzeichnisse verweisen, als Kernel-Fehler angesehen werden könnte. (Technischer Hinweis:Es können mehrere Dateisysteme übereinander im Root eingehängt sein; setns() verwendet die oberste, zuletzt montierte).

Dies veranschaulicht einen Vorteil der Kombination eines Mount-Namensraums mit einem „PID-Namensraum“. In einem PID-Namespace zu sein, würde Sie daran hindern, den Mount-Namespace eines uneingeschränkten Prozesses zu betreten. Es verhindert auch, dass Sie das Stammverzeichnis eines unbeschränkten Prozesses eingeben (/proc/$PID/root ). Und natürlich hindert Sie ein PID-Namensraum auch daran, einen Prozess zu beenden, der sich außerhalb befindet :-).