Wie fakeroot ist keine Sicherheitslücke in Linux?

Nachdem ich ein paar hübsche Antworten auf diese Frage gelesen habe , bin ich immer noch unschlüssig, warum Sie so tun möchten, als wären Sie root, ohne die Vorteile zu nutzen, die es mit sich bringt, tatsächlich root zu sein.

Bisher kann ich feststellen, dass fakeroot verwendet wird, um einer Datei den Besitz zu geben, die root sein muss, wenn sie entpackt / tariert wird. Meine Frage ist, warum kannst du das nicht einfach mit chown machen?

Eine Diskussion in Google Groups hier zeigt, dass Sie fakeroot benötigen, um einen Debian-Kernel zu kompilieren (wenn Sie dies von einem nicht privilegierten Benutzer möchten). Mein Kommentar ist, dass der Grund, warum Sie root sein müssen, um zu kompilieren, wahrscheinlich darin liegt, dass für andere Benutzer keine Leseberechtigungen festgelegt wurden. Wenn ja, ist es keine Sicherheitsverletzung, die fakeroot für die Kompilierung zulässt (was bedeutet, dass gcc jetzt eine Datei lesen kann, die für root bestimmt war)?

Diese Antwort hier beschreibt , dass die tatsächlichen Systemaufrufe mit echten gemacht werden uid / gid des Benutzers , so wieder , wo tut fakeroot Hilfe?

Wie stoppt fakeroot unerwünschte Rechteerweiterungen unter Linux? Wenn fakeroot tar dazu verleiten kann, eine Datei zu erstellen, deren Eigentümer root ist, warum nicht mit SUID etwas Ähnliches tun?

Nach allem, was ich gesammelt habe, ist fakeroot nur nützlich, wenn Sie den Eigentümer von Paketdateien ändern möchten, die Sie für root erstellt haben. Aber Sie können das mit chown tun. Wo fehle ich also in meinem Verständnis, wie diese Komponente verwendet werden soll?

Bisher kann ich feststellen, dass fakeroot verwendet wird, um einer Datei den Besitz zu geben, die root sein muss, wenn sie entpackt / tariert wird. Meine Frage ist, warum kannst du das nicht einfach mit chown machen?

Weil du das nicht einfach mit machen kannst chown, zumindest nicht als Nicht-Root-Benutzer. (Und wenn Sie als Root ausgeführt werden, müssen Sie das nicht tun fakeroot.) Das ist der springende Punkt fakeroot: Programme, die als Root ausgeführt werden sollen, können als normaler Benutzer ausgeführt werden, während sie so tun, als ob die für Root erforderlichen Vorgänge erfolgreich wären.

Dies wird normalerweise beim Erstellen eines Pakets verwendet, damit der Installationsprozess des zu installierenden Pakets fehlerfrei fortgesetzt werden kann (auch wenn es ausgeführt wird chown root:root, oder install -o rootusw.). fakerooterinnert sich an den gefälschten Besitz, den es vorgab, Dateien zu geben, so dass nachfolgende Operationen, die den Besitz betrachten, dies anstelle des wirklichen sehen; Auf diese Weise können nachfolgende tarLäufe beispielsweise Dateien als Eigentum von root speichern.

Wie stoppt fakeroot unerwünschte Rechteerweiterungen unter Linux? Wenn fakeroot tar dazu verleiten kann, eine Datei zu erstellen, deren Eigentümer root ist, warum nicht mit SUID etwas Ähnliches tun?

fakerootEs werden keine tarÄnderungen übernommen, die vom Build vorgenommen werden sollen, ohne dass diese Änderungen auf dem System wirksam werden, auf dem sich der Build befindet. Sie müssen keinen fakerootTarball erstellen, der eine Datei enthält, die root und suid gehört. Wenn Sie über eine Binärdatei verfügen evilbinary, wird beim Ausführen tar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryals normaler Benutzer ein Tarball erstellt evilbinary, der root und suid gehört. Sie können diesen Tarball jedoch nicht extrahieren und diese Berechtigungen beibehalten, es sei denn, Sie tun dies als root: Hier gibt es keine Eskalation von Berechtigungen. fakerootist ein Privileg de-escalation tool: Ermöglicht das Ausführen eines Builds als normaler Benutzer unter Beibehaltung der Effekte, die der Build gehabt hätte, wenn er als Root ausgeführt worden wäre, sodass diese Effekte später wiedergegeben werden können. Das Anwenden der Effekte "für echt" erfordert immer Root-Rechte. fakerootbietet keine Methode, um sie zu erwerben.

Um die Verwendung fakerootgenauer zu verstehen , sollten Sie berücksichtigen, dass ein typischer Distributionsbuild (unter anderem) die folgenden Vorgänge umfasst:

• Installiere Dateien, die root gehören
• ...
• Archivieren Sie diese Dateien, die immer noch im Besitz von root sind, damit sie beim Extrahieren im Besitz von root sind

Der erste Teil schlägt offensichtlich fehl, wenn Sie nicht root sind. Wenn Sie jedoch fakerootals normaler Benutzer unter ausgeführt werden, wird der Prozess

• Dateien installieren, die root gehören - dies schlägt fehl, fakerootgibt aber vor, erfolgreich zu sein, und merkt sich den geänderten Besitz
• ...
• Archivieren Sie diese Dateien, die immer noch im Besitz von root sind. Wenn tardas System gefragt wird, was der Dateibesitz ist (oder welcher Archiver auch immer verwendet wird), fakerootwird die Antwort so geändert, dass sie dem zuvor aufgezeichneten Besitz entspricht

Auf diese Weise können Sie einen Paket-Build ausführen, ohne root zu sein, und dabei dieselben Ergebnisse erzielen, die Sie erhalten würden, wenn Sie wirklich als root ausgeführt würden. Die Verwendung fakerootist sicherer: Das System kann immer noch nichts tun, was Ihr Benutzer nicht kann, sodass ein nicht autorisierter Installationsprozess Ihr System nicht beschädigen kann (außer durch Berühren Ihrer Dateien).

In Debian wurden die Build-Tools verbessert, um dies nicht mehr zu erfordern, und Sie können Pakete ohne sie erstellenfakeroot . Dies wird dpkgdirekt mit der Rules-Requires-RootDirektive unterstützt (siehe rootless-builds.txt).

Um den Zweck fakerootund die Sicherheitsaspekte der Ausführung als Root zu verstehen oder nicht, kann es hilfreich sein, den Zweck der Paketierung zu berücksichtigen. Wenn Sie eine Software aus dem Quellcode installieren, um sie systemweit zu verwenden, gehen Sie wie folgt vor:

1. Erstellen Sie die Software (die ohne Berechtigungen durchgeführt werden kann)
2. Installieren Sie die Software (die als Root ausgeführt werden muss oder zumindest als Benutzer, der zum Schreiben an die entsprechenden Systemspeicherorte berechtigt ist).

Wenn Sie eine Software packen, verzögern Sie den zweiten Teil. Um dies jedoch erfolgreich zu tun, müssen Sie die Software weiterhin im Paket und nicht auf dem System "installieren". Wenn Sie also Software paketieren, wird der Prozess zu:

1. Erstellen Sie die Software (ohne besondere Rechte)
2. vorgeben, die Software zu installieren (erneut ohne besondere Rechte)
3. Erfassen der Softwareinstallation als Paket (dito)
4. das paket zur verfügung stellen (dito)

Jetzt schließt ein Benutzer den Vorgang ab, indem er das Paket installiert, das als root ausgeführt werden muss (oder erneut einen Benutzer mit den entsprechenden Berechtigungen, um an die entsprechenden Speicherorte zu schreiben). Hier wird der verzögerte privilegierte Prozess verwirklicht und ist der einzige Teil des Prozesses, der spezielle Privilegien benötigt.

fakeroot Hilft bei den obigen Schritten 2 und 3, indem es uns ermöglicht, Softwareinstallationsprozesse auszuführen und deren Verhalten zu erfassen, ohne als Root ausgeführt zu werden.

NEIN. Fake Root ermöglicht es Ihnen, Berechtigungsmanipulations- und Berichterstellungstools auszuführen, die konsistent berichten. Diese Berechtigungen werden jedoch nicht gewährt. Es wird so aussehen, als hättest du sie (falsch). Es ändert nichts außerhalb der Umgebung.

Es ist nützlich, wenn Sie eine Verzeichnisstruktur erstellen möchten, die Eigentumsrechte und Berechtigungen enthält, die von Ihrem Benutzer nicht festgelegt werden konnten, und dann tar, zip oder ein anderes Paket.

Es erhöht nicht wirklich die Berechtigungen, es ist eine Fälschung. Sie können nichts tun (löschen, schreiben, lesen), was Sie sonst nicht tun könnten. Sie könnten das Paket (theoretisch) ohne es produzieren. Sie könnten einen gefälschten Bericht ( ls) ohne ihn erhalten.

Es ist keine Sicherheitslücke, da es keinen Zugriff erlaubt oder alles, was Sie nicht ohne sie tun können. Es läuft ohne Privileg. Alles , was es Dosis ist abfangen Anrufe chown, chmodusw. Es macht sie eine No-Operation, mit der Ausnahme , dass es , was wäre geschehen , aufzeichnet. Außerdem werden Aufrufe an statusw. abgefangen, sodass Berechtigungen und Eigentumsrechte aus der eigenen internen Datenbank gemeldet werden, als ob die anderen Befehle ausgeführt worden wären. Dies ist nützlich, da das Verzeichnis, wenn Sie es anschließend komprimieren, über die falschen Berechtigungen verfügt. Wenn Sie dann als root entpacken, werden die Berechtigungen real.

Dateien, die vorher nicht lesbar / beschreibbar waren, bleiben nicht lesbar / beschreibbar. Alle speziellen Dateien (z. B. Geräte), die erstellt wurden, haben keine besonderen Befugnisse. Bei jeder Set-UID (für einen anderen Benutzer) werden Dateien nicht mit der Set-UID versehen. Alle anderen Rechteerweiterungen funktionieren nicht.

Dies ist eine Art virtueller Maschine: Eine virtuelle Maschine kann im Allgemeinen eine beliebige Umgebung / ein beliebiges Betriebssystem simulieren, kann jedoch nichts für den Host tun, was keine andere Anwendung tun könnte. Innerhalb der virtuellen Maschine können Sie scheinbar alles tun. Sie können das Sicherheitssystem neu erfinden, sodass es gleich oder verschieden ist. Dies ist jedoch alles auf dem Host vorhanden, da es sich um Ressourcen handelt, die dem Benutzer / der Gruppe des Prozesses gehören, der die virtuelle Umgebung ausführt.

Es gibt hier bereits zwei gute und sehr detaillierte Antworten, aber ich möchte nur darauf hinweisen, dass der einleitende Absatz der ursprünglichen fakeroot Manpage ^{1 dies} tatsächlich ziemlich klar und prägnant erklärt:

fakeroot führt einen Befehl in einer Umgebung aus, in der er anscheinend über Root-Berechtigungen für die Dateibearbeitung verfügt. Dies ist nützlich, damit Benutzer Archive (tar, ar, .deb usw.) mit Dateien erstellen können, die über Root-Berechtigungen verfügen. Ohne fakeroot müsste man root-Rechte haben, um die Dateien der Archive mit den richtigen Berechtigungen und Inhabern zu erstellen und sie dann zu packen, oder man müsste die Archive direkt erstellen, ohne den Archivierer zu verwenden.

Mit Fakeroot kann ein Benutzer ohne Rootberechtigung Archive mit Dateien erstellen, die sich im Besitz des Rootberechtigten befinden. Dies ist ein wichtiger Bestandteil der Generierung und Verteilung von Binärsoftwarepaketen unter Linux. Ohne fakerootmüssten Paketarchive generiert werden, während sie als tatsächlicher Root ausgeführt werden, damit sie die richtigen Dateieigentümer und Berechtigungen enthalten. Das wäre ein Sicherheitsrisiko. Das Erstellen und Packen potenziell nicht vertrauenswürdiger Software ist ein großes Risiko, wenn Root-Rechte verwendet werden. Dank fakerootkönnen nichtprivilegierte Benutzer mit nichtprivilegierten Dateien weiterhin Archive erstellen, die Dateien mit Root-Eigentümern enthalten. ²

Aber es ist kein Sicherheitsrisiko dar , weil nichts im Archiv ist tatsächlich im Besitz von Root , bis die Dateien GEWONNEN . Und selbst dann werden die Dateien nur dann mit intakten Root-Berechtigungen extrahiert, wenn dies von einem privilegierten Benutzer durchgeführt wird. In diesem Schritt, in dem ein fakerootunterstütztes Archiv, das "root" -Dateien enthält, von einem privilegierten Benutzer extrahiert wird, wird der "fake" -Root schließlich real. Bis zu diesem Zeitpunkt werden keine tatsächlichen Root-Berechtigungen erhalten oder umgangen.

Anmerkungen

1. Fakeroot hat einige Konkurrenten / Nachahmer hervorgebracht, die sich wie fakerootinstalliert tarnen , einschließlich fakeroot-ngund pseudo. Aber meiner Meinung nach ist weder die Manpage "Nachahmer" so klar, wie es ist, auf den Punkt in dieser Frage zu kommen. Bleib beim Original, einzigem fakerootOG

2. Andere Distributionen / Verpackungssysteme umgehen dies, indem sie in ihren Paketarchiven einfach kein Root-Eigentum verwenden. Unter Fedora kann beispielsweise Software von einem nicht privilegierten Benutzer kompiliert, installiert und gepackt werden, ohne dass dies erforderlich ist fakeroot. Es wird alles im $HOME/rpmbuild/Raum des Benutzers erledigt , und normal privilegierte Schritte wie make installdas Umleiten (über Mechanismen wie --prefixund DESTDIR) in eine $HOME/rpmbuild/BUILDROOT/Hierarchie, die als eine Art "fakechroot" -Raum angesehen werden könnte (ohne sie tatsächlich zu verwenden fakechroot).

   Aber auch währenddessen make installwird alles als und im Besitz des nicht privilegierten Benutzers ausgeführt. Extrahierte Dateieigentümer und Berechtigungen werden standardmäßig auf root,rootund 0644(oder 0755für ausführbare Dateien) gesetzt, sofern sie nicht in der Paketdefinitionsdatei ( .spec) überschrieben werden. In diesem Fall werden sie als Metadaten im endgültigen Paket gespeichert. Da vor dem (privilegierten) Installationsprozess des RPM-Pakets keine Berechtigungen oder Eigentumsrechte angewendet werden, fakerootwird beim Packen weder Root noch benötigt. Ist fakerootaber wirklich nur ein anderer Weg zum selben Ergebnis.