Um einer Diskussion, die ich führe, mehr Gewicht zu verleihen, versuche ich, konkrete Beispiele dafür zu finden, warum es aus Sicherheitssicht schlecht ist, wenn das Verzeichnis /root für alle lesbar ist.
Ich habe im Internet zahlreiche Beispiele dafür gefunden, dass Leute das Mantra wiederholen, dass es wirklich nicht gut sei, /root beispielsweise 755 Rechte zu geben, ohne dafür jedoch weitere Beweise zu liefern.
Könnte jemand bitte ein Szenario beschreiben, in dem die Sicherheit eines Systems in einem solchen Fall gefährdet sein kann? Je weniger gekünstelt, desto besser – wie kann beispielsweise ein frisch installiertes Centos-System darunter leiden, wenn /root 755 Berechtigungen hat?
EDIT - Danke für die Antworten, aber bisher keine konkreten Beispiele. Anders ausgedrückt: Wie könnten Sie die Tatsache, dass /root sichtbar ist, nutzen, um das System zu kompromittieren? Gibt es Beispiele für die Installation von Programmen und die Annahme, dass /root nicht für alle zugänglich ist?
BEARBEITEN 2 – Ich denke, bisher herrscht Konsens darüber, dass es kein großes Sicherheitsrisiko darstellt, abgesehen davon, dass jemand die Berechtigungen nicht überprüft und das Verzeichnis verwendet, als wäre es privat für den Root-Benutzer.
Antwort1
Dies unterscheidet sich grundsätzlich nicht von der Empfehlung, andere Benutzer daran zu hindern, das Home-Verzeichnis eines anderen Benutzers zu lesen.
Wenn die Standardeinstellung allgemein lesbar ist, gibt es ein Zeitfenster, in dem Sie eine neue Datei speichern, die Sie privat halten möchten. Es besteht immer die Möglichkeit, dass jemand sie kopiert, bevor Sie chmod go-res können.
Antwort2
Im Grunde genommen ist es meiner Meinung nach eine Entscheidung der Kernentwickler und nichts weiter. Warum? Weil standardmäßig fast nichts Wertvolles für irgendjemanden in enthalten sein sollte /root. Niemand sollte sich für allgemeine Dinge als Root-Benutzer anmelden.
Unter FreeBSD kann beispielsweise jeder lesen /root. Einige Dateien darin /rootkönnen aus Sicherheitsgründen nicht gelesen werden, aber Sie können trotzdem „sehen“, dass diese Dateien vorhanden sind ls(können sie nur nicht lesen). Beispielsweise .historyist festgelegt , -rw-------aber .loginist -rw-r--r--.
FreeBSD verfolgt einen etwas anderen Sicherheitsansatz als Linux. Historisch gesehen wurde FreeBSD für Server entwickelt und obwohl es als Desktop ausgeführt werden kann, ist es (standardmäßig) als Server wirklich besser geeignet.
Persönlich sehe ich an dieser Konfiguration nichts Falsches ( /rootkann nachgelesen werden).
Unter /rootFreeBSD ist außer Konfigurationen eigentlich fast nichts darin. E-Mails sollten an einen echten Benutzer weitergeleitet werden. Niemand sollte sich als Root-Benutzer anmelden. Das Konto sollte nur für die Installation und Konfiguration von Software sowie für Wartungsaufgaben verwendet werden. Abgesehen von einigen sicherheitsrelevanten Dateien (wie .history) gibt es /rootunter FreeBSD meiner Meinung nach nichts zu verbergen.
Weitere Informationen zu diesem Thema finden Sie imAbschnitt „Sicherheit“ im FreeBSD-Handbuch. Ich habe bei einem schnellen Überfliegen nichts über ihre Wahl lesbar gesehen, /rootaber es gibt dort eine Menge Informationen.
Antwort3
Möglicherweise sucht ein unvorsichtiger Administrator nach leicht zu knackenden Passwörtern und lässt die Ausgabe liegen (das ist vielleicht nicht der richtige Aufruf, aber Sie verstehen, was ich meine):
# john-the-ripper /etc/shadow > ~/cracked-passwords.txt
Antwort4
Wenn ~rootbeschreibbar wäre, könnte jeder Benutzer seinen SSH-Schlüssel zu hinzufügen ~root/.ssh/authorized_keysund hätte dann einfach über Root-Zugriff ssh root@some-host.
Wenn ~rootes „nur“ lesbar ist, haben Sie immer noch Zugriff auf die Datei rootdes Benutzers .bash_history, die Passwörter oder andere Anmeldeinformationen enthalten könnte, die in der Befehlszeile eingegeben oder versehentlich in eine Eingabeaufforderung eingegeben oder eingefügt wurden.
Natürlich sollten Sie keine sicheren Daten über die Befehlszeile weitergeben, aber diese Warnung wird im Allgemeinen als risikoarm eingestuft, da es riskant ist, sie während der Übertragung abzufangen, und andere Benutzer sollten Ihre Umgebungsvariablen ohnehin nicht lesen können. Wenn Sie Zugriff auf die Datei haben root, .bash_historyhaben Sie Zugriff auf alle vertraulichen Daten, die rootauf diese Weise möglicherweise eingegeben wurden, ob versehentlich oder nicht.
Sicher, es gibt Abhilfen für diese Probleme, wie z. B. das Verbot rootder Anmeldung bei SSH, selbst mit Schlüsselauthentifizierung. Oder das Deaktivieren des Shell-Verlaufs. Oder das sorgfältige Aufräumen. Aber das sindMilderungen; sie sind Schichten in der Sicherheitszwiebel.
Die ~rootZeit 07:00 ist eine weitere Schicht dieser Sicherheitszwiebel. Wenn Sie nicht weinen möchten, schälen Sie die Zwiebel nicht mehr als nötig.