Frage Warum ist "chmod -R 777 /" destruktiv?


Das ist ein Kanonische Frage über Dateiberechtigungen und Warum 777 ist "destruktiv".

Ich frage nicht, wie man dieses Problem beheben kann, da es eine Menge Referenzen davon bereits auf Server Fault gibt (OS neu installieren). Warum macht es überhaupt etwas Zerstörendes?

Wenn Sie diesen Befehl jemals ausgeführt haben, zerstören Sie Ihr Betriebssystem sofort. Mir ist nicht klar, warum das Entfernen von Beschränkungen irgendwelche Auswirkungen auf bestehende Prozesse hat. Zum Beispiel, wenn ich keinen Lesezugriff auf etwas habe und nach einem schnellen Tipp im Terminal plötzlich habe ich jetzt einen guten Zugang ... Warum bricht Linux dann?


246
2018-02-28 21:25


Ursprung


Ich habe den Atem angehalten, als ich diese Frage gesehen habe. - Alireza Savand


Antworten:


Vor allem eine kleine Terminologie Nitpick: chmod nicht Löschen Berechtigungen. Es ÄNDERUNGEN Sie.


Jetzt das Fleisch der Ausgabe - Der Modus 777 bedeutet "Jeder kann diese Datei lesen, schreiben oder ausführen" - Sie haben Erlaubnis gegeben für jeden (effektiv) zu tun, was immer sie wollen.

Nun, warum ist das schlimm?

  1. Sie haben gerade alle Dateien auf Ihrem System lesen / ändern lassen.
    • Kiss Passwort Sicherheit auf Wiedersehen (jeder kann die Schatten-Datei lesen und knacken Sie Ihre Passwörter, aber warum stören? Ändern Sie einfach das Passwort! Es ist viel einfacher!).
    • Kiss Sicherheit für Ihre Binaries tschüss (jemand kann einfach einen neuen schreiben login Programm, das sie in jeder Zeit lässt).
    • Küssen Sie Ihre Dateien auf Wiedersehen: Ein Benutzer fädelt fehl rm -r / und es ist alles vorbei. Das OS wurde aufgefordert, sie machen zu lassen, was sie wollten!
  2. Sie haben jedes Programm angepisst, das die Berechtigungen für Dateien vor dem Start überprüft.
    sudo, sendmail, und eine Schar anderer wird einfach nicht mehr anfangen. Sie werden die Schlüsseldateiberechtigungen untersuchen, sehen, dass sie nicht das sind, was sie sein sollen, und eine Fehlermeldung zurückwerfen.
    Ähnlich ssh wird schrecklich brechen (Schlüsseldateien müssen bestimmte Berechtigungen haben, andernfalls sind sie "unsicher" und standardmäßig verweigert SSH die Verwendung.)
  3. Sie haben die Setuid / Setgid-Bits in den Programmen gelöscht, die sie hatten.
    Der Modus 777 ist eigentlich 0777. Unter den Dingen in dieser führenden Ziffer sind die setuid und setgid Bits.
    Die meisten Programme, die setuid / setgid sind, haben dieses Bit gesetzt, weil sie mit bestimmten Privilegien laufen müssen. Sie sind jetzt gebrochen.
  4. Du hast gebrochen /tmp und /var/tmp Die andere Sache in dieser führenden oktalen Ziffer, die Null wurde, ist die sticky bit - Das schützt Dateien in /tmp (und /var/tmp) von Personen gelöscht werden, die sie nicht besitzen.
    Es gibt (leider) viele schlecht benehmte Skripte da draußen, die "aufräumen", indem sie einen machen rm -r /tmp/*und ohne das Sticky-Bit gesetzt /tmp  Sie können alle Dateien in diesem Verzeichnis auf Wiedersehen küssen.
    Scratch-Dateien verschwinden zu lassen kann einige schlecht geschriebene Programme wirklich stören ...
  5. Du hast Chaos angerichtet /dev  /proc und ähnliche Dateisysteme
    Dies ist eher ein Problem bei älteren Unix-Systemen /devist ein echtes Dateisystem und das Zeug, das es enthält, sind spezielle Dateien, mit denen es erstellt wurde mknodDie Änderung der Berechtigungen bleibt über Neustarts hinweg erhalten, aber auf jedem System, das die Zugriffsrechte für Ihr Gerät hat, können erhebliche Probleme entstehen, von den offensichtlichen Sicherheitsrisiken (jeder kann jedes TTY lesen) bis zu den weniger offensichtlichen möglichen Ursachen eines Kernel Panic.
    Credit to @Tonny for pointing out this possibility
  6. Steckdosen und Rohre können brechen oder andere Probleme haben Steckdosen und Rohre können vollständig zerbrechen oder schädlichen Einschleusungen ausgesetzt sein, da sie weltweit beschreibbar sind.
    Credit to @Tonny for pointing out this possibility
  7. Sie haben jede Datei auf Ihrem System ausführbar gemacht
    Viele Leute haben . in ihren PATH Umgebungsvariable (das solltest du nicht!) - Dies könnte zu einer unangenehmen Überraschung führen, da jetzt jeder eine Datei ablegen kann, die bequem wie ein Befehl benannt ist (sagen wir mal make oder lsund versuchen Sie, ihren schädlichen Code auszuführen.
    Credit to @RichHomolka for pointing out this possibility
  8. Auf einigen Systemen chmod wird die Zugriffssteuerungslisten (ACLs) zurücksetzen
    Das bedeutet, dass Sie möglicherweise alle Ihre ACLs neu erstellen müssen, zusätzlich zu den Berechtigungen überall korrigieren (und dies ist ein aktuelles Beispiel für den Befehl, der destruktiv ist).
    Credit to @JamesYoungman for pointing out this possibility

Laufen die Teile des Systems, die bereits laufen, weiter? Wahrscheinlich, zumindest für eine Weile.
Aber das nächste Mal, wenn Sie ein Programm starten müssen, oder einen Dienst neu starten müssen, oder Himmel REBOOT die Box, in der Sie für eine Welt der Verletzung sind als # 2 und # 3 oben häuten ihre hässlichen Köpfe zu verhindern.


335
2018-02-28 21:46



Zumindest auf einigen Systemen /tmp würde nach einem Neustart behoben werden. Obwohl alles andere scheint gebrochen zu sein. Zumindest in der VM, die ich gerade getestet habe, scheint ein Neustart den behoben /tmp Berechtigungen. Irgendwo muss irgendwo ein Startscript stehen. - Zoredache
@Zoredache Systeme, die verwenden tmpfs in der Regel reparieren sie sich selbst, diejenigen, die / tmp auf der Festplatte haben kann (hängt von ihren Startskripten ab) - voretaq7
+1, um darauf hinzuweisen, dass setuid und setgid eliminiert werden. Dies ist ein sehr zerstörerischer Aspekt. Versuche zu laufen find / -perms -4000 -type f und find / -perms -2000 -type f um verschiedene Binärdateien zu sehen, die sich auf diese Flags verlassen. - Kyle Smith
Wenn Sie etwas wie "less foo.txt" eingeben, wird keine Datei namens less.txt ausgeführt, die herumliegt, unabhängig davon, ob das ausführbare Bit gesetzt ist. Sie müssten das Verzeichnis less.txt in Ihrem Pfad haben und Sie müssten "less.txt foo.txt" eingeben - nicht wirklich eine zufällige Sache dort. Selbst wenn Sie die Shell-Vervollständigung verwenden würden, würde es bei weniger stoppen und Sie müssten immer noch die .txt hinzufügen. Um eine zufällige Textdatei mit ausführbarem Bit-Set aufzurufen, müssten Sie ./nameoffile.txt. - The Real Bill
@ Deji everyone ist definiert als die Vereinigung von Menge einschließlich des Benutzers, der die Datei besitzt, der Benutzer in der Gruppe, die die Datei besitzt, und der Benutzer, die keines dieser Kriterien erfüllen (wörtlich die drei oktalen Berechtigungsziffern: User, Group, und Other). Mit anderen Worten Jeder Benutzer mit Zugriff auf das System. ("Zugriff" in diesem Kontext könnte ein Shell-Account sein, wie ich es normalerweise ansprechen würde, aber es beinhaltet auch den Zugriff über ein Webformular / CGI, das Daten auf einen Datenträger schreibt: Der www Benutzer kann nun in jede Datei auf dem System schreiben, was auch zufällige Besucher bedeuten kann.) - voretaq7


Eine wichtige Sache ist, dass es viele Tools wie ssh / sudo gibt, die die Dateisystemberechtigungen für Schlüsselkonfigurationsdateien überprüfen. Wenn die Berechtigungen falsch sind, sind diese Tools fehlgeschlagen, da dies ein schwerwiegendes Sicherheitsproblem anzeigen würde. Auf meinem Debian-Testsystem und vielleicht auch bei anderen schlägt die Login-Fähigkeit fehl, wahrscheinlich weil die Login-Binärdatei oder etwas in PAM Berechtigungsprüfungen hat.

Es ist also nicht wirklich, dass das System zerstört wird - es ist so, dass viele Tools so konzipiert sind, dass sie sofort fehlschlagen, wenn die Berechtigungen falsch sind.

Wenn Sie ein System neu starten, nachdem Sie a chmod 777 -R / Es wird gestartet und Sie können Prozesse starten, die keine expliziten Berechtigungsprüfungen haben. Das System ist also nicht wirklich tot, nur etwas unbrauchbar von Entwurf.


100
2018-02-28 21:33