GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Warum ist chmod -R 777 / destruktiv?

Lösung 1:

Zunächst einmal ein kleiner Begriffsnarr:chmod nicht entfernt Berechtigungen. Es ÄNDERT sich Sie.

Nun zum Kern des Problems – Der Modus 777 bedeutet "Jeder kann diese Datei lesen, schreiben oder ausführen" - Sie haben die Erlaubnis erteilt damit jeder (effektiv) tun kann, was er will.

Nun, warum ist das schlimm?

  1. Sie haben gerade allen erlaubt, jede Datei auf Ihrem System zu lesen/zu ändern.
    • Verabschieden Sie sich von der Passwortsicherheit (jeder kann die Shadow-Datei lesen und Ihre Passwörter knacken, aber warum sich die Mühe machen? ÄNDERN Sie einfach das Passwort! Es ist viel einfacher!).
    • Verabschieden Sie sich von der Sicherheit Ihrer Binärdateien (jemand kann einfach einen neuen login schreiben Programm, das sie jedes Mal reinlässt).
    • Verabschieden Sie sich von Ihren Dateien:Ein Benutzer leitet rm -r / fehl und es ist alles vorbei. Das Betriebssystem wurde angewiesen, sie tun zu lassen, was sie wollten!
  2. Sie haben jedes Programm verärgert, das vor dem Start Berechtigungen für Dateien überprüft.
    sudo , sendmail , und viele andere starten einfach nicht mehr. Sie werden die Berechtigungen von Schlüsseldateien untersuchen, feststellen, dass sie nicht das sind, was sie sein sollten, und eine Fehlermeldung zurückwerfen.
    Ebenso ssh wird fürchterlich kaputt gehen (Schlüsseldateien müssen bestimmte Berechtigungen haben, sonst sind sie "unsicher" und standardmäßig weigert sich SSH, sie zu verwenden.)
  3. Sie haben die setuid / setgid-Bits in den Programmen gelöscht, die sie hatten.
    Der Modus 777 ist eigentlich 0 777 . Zu den Dingen in dieser führenden Ziffer gehört 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 kaputt.
  4. Sie haben /tmp gebrochen und /var/tmp Die andere Sache in dieser führenden Oktalziffer, die auf Null gesetzt wurde, ist die sticky bit -- Das, was Dateien in /tmp schützt (und /var/tmp ) nicht von Personen gelöscht werden, die sie nicht besitzen.
    Es gibt (leider) viele schlecht erzogene Skripte, die "aufräumen", indem sie einen rm -r /tmp/* ausführen , und ohne das auf /tmp gesetzte Sticky-Bit Sie können sich von allen Dateien in diesem Verzeichnis verabschieden.
    Das Verschwinden von Scratch-Dateien kann einige schlecht geschriebene Programme wirklich stören...
  5. Du hast in /dev Chaos angerichtet /proc und ähnliche Dateisysteme
    Dies ist eher ein Problem auf älteren Unix-Systemen, auf denen /dev ist ein echtes Dateisystem, und das Zeug, das es enthält, sind spezielle Dateien, die mit mknod erstellt wurden , da die Änderung der Berechtigungen über Neustarts hinweg beibehalten wird, aber auf jedem System, auf dem sich Ihre Geräteberechtigungen ändern, erhebliche Probleme verursachen können, von den offensichtlichen Sicherheitsrisiken (jeder kann jedes TTY lesen) bis zu den weniger offensichtlichen möglichen Ursachen einer Kernel-Panik.
    Credit to @Tonny for pointing out this possibility
  6. Buchsen und Rohre können brechen oder andere Probleme haben Sockets und Pipes können vollständig brechen oder einer böswilligen Injektion ausgesetzt werden, da sie weltweit beschreibbar gemacht wurden.
    Credit to @Tonny for pointing out this possibility
  7. Sie haben jede Datei auf Ihrem System ausführbar gemacht
    Viele Leute haben . in ihrem PATH Umgebungsvariable (sollten Sie nicht!) - Dies könnte zu einer unangenehmen Überraschung führen, da jetzt jeder eine Datei mit dem bequemen Namen eines Befehls (z. B. make) löschen kann oder ls , und versuchen Sie, Sie dazu zu bringen, ihren bösartigen Code auszuführen.
    Credit to @RichHomolka for pointing out this possibility
  8. Auf einigen Systemen chmod setzt Access Control Lists (ACLs) zurück
    Dies bedeutet, dass Sie möglicherweise alle Ihre ACLs neu erstellen müssen und außerdem überall Berechtigungen reparieren müssen (und dies ist ein tatsächliches Beispiel dafür, dass der Befehl destruktiv ist).
    Credit to @JamesYoungman for pointing out this possibility

Laufen die bereits laufenden Anlagenteile weiter? Wahrscheinlich zumindest für eine Weile.
Aber das nächste Mal, wenn Sie ein Programm starten oder einen Dienst neu starten oder, Gott bewahre, die Box NEU BOOTEN müssen, sind Sie in einer Welt voller Schmerzen, da Nr. 2 und Nr. 3 oben ihre hässlichen Köpfe erheben werden.

Lösung 2:

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

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

Wenn Sie ein System neu starten, nachdem Sie chmod 777 -R / ausgeführt haben 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 by-design .


Linux
  1. Linux-Berechtigungen:Eine Einführung in chmod

  2. Wie sortiert man Dateien nach ihren Berechtigungen mit Ls?

  3. Erfahren Sie, wie Sie Berechtigungen für Dateien und Ordner ändern

  4. Warum sind .so-Dateien ausführbar?

  5. Was häufiger verwendet wird:chmod 777 oder chmod a+rwx

So ändern Sie Berechtigungen für Dateien und Verzeichnisse

Chmod-Befehl in Linux (Dateiberechtigungen)

So ändern Sie die Dateiberechtigungen in Linux rekursiv

Was bedeutet chmod 777

Chmod-Befehl unter Linux

Linux-Chmod-Befehlsbeispiele