it-swarm.com.de

Grund, chmod -R 777 nicht auf internem Server für Projektquellcode zu verwenden?

Seit meiner Zeit der Amateur-Webentwicklung hat mich das Prinzip des geringsten Privilegs geschlagen, chmod -R 777 dir Nicht zu verwenden. Ich persönlich habe es nie gebraucht, also habe ich es nie benutzt.

Ich arbeite jetzt professionell in einem Entwicklungsteam und wir haben kürzlich ausführbaren Code auf einen gemeinsam genutzten internen Server verschoben. Nur Mitarbeiter des Unternehmens können auf den Server zugreifen, und wir vertrauen allen Mitarbeitern unseres Unternehmens. Der Code ist sowieso nicht besonders sensibel.

Ich versuche ein Skript auszuführen Dass ein anderes Teammitglied in den freigegebenen Ordner schrieb, verursachte einen Berechtigungsfehler. "Nur um zu überprüfen, ob es sonst funktionieren würde" führte ein Mitarbeiter chmod -R 777 /opt/path/to/shared/folder An dem Projekt. Sobald es funktioniert hat, sagte der Mitarbeiter, es sei in Ordnung, es so zu belassen, wie es ist, anstatt für uns zu einer kontrollierten groups Lösung zu wechseln.

Weil ich ein Schimpanse bin Ich möchte laut sprechen und sagen, dass dies eine schlechte Praxis ist und wir sie in eine groups Lösung ändern sollten. Nach einigen Überlegungen kann ich jedoch keinen Grund finden, warum gemeinsam genutzter ausführbarer Code auf einem internen Server keine 777 - Berechtigungen haben sollte.

Gibt es aus Sicherheitsgründen einen Grund, die Berechtigungen unseres Projektordners von 777 In etwas zu ändern, das mit groups etwas enger verknüpft ist?


† Die Berechtigungsanforderungen für diese Skripte können nicht geändert werden.

46
user1717828

Nachdem ich mir einige Gedanken darüber gemacht habe, kann ich keinen Grund finden, warum gemeinsam genutzter ausführbarer Code auf einem internen Server keine 777-Berechtigungen haben sollte.

Da Sie nicht nur jedem Benutzer vertrauen - was auf einem internen Server sinnvoll sein kann, auf den "jeder", der Zugriff hat, diese Kontrolle haben sollte -, vertrauen Sie auch jedem Prozess auf diesem Server. Der Webserver. Der SSH-Server. Der DHCP-Client. Jede geplante Aufgabe und jeder Service. Sogar Prozesse, die als "niemand" und "keine Gruppe" ausgeführt werden. Alle Arten von Prozessen, die von einem Angreifer genutzt werden können, um seinen Zugriff zu erlangen oder zu erweitern.

Denn wenn Sie in der internen Entwicklung so schlampig sein wollen, wird jemand auf einem Produktions- oder Kundensystem so schlampig sein, weil "so haben wir es intern behoben".

Da ein Angreifer gerne dieses kleine System findet, das nur intern und nicht wichtig oder geschützt ist, erkennt er Schwachstellen wie beschreibbare Webanwendungsdateien, verwendet sie, um auf das System zuzugreifen und es zu nutzen, um irgendwohin zu gelangen. Ich wette, die Passwörter, die auf diesem System verwendet werden, funktionieren auch auf anderen, wertvolleren internen Systemen. Vielleicht verwenden Sie das gleiche Root-Passwort auch auf allen Servern? Das macht immer Spaß.

97
gowenfawr

Ich werde @gowenfawr unterstützen und sagen, dass das Züchten besserer Schimpansen ein Ziel für sich ist. (jetzt werde ich wild über Ihre extrapolieren Unternehmenskultur)

In meinem Softwareentwicklungsunternehmen beobachten wir einen zunehmenden Trend von Kunden, die nicht nur in Produktionsumgebungen, sondern auch in unserem Entwicklungsprozess und in der Unternehmens-IT im Allgemeinen nach Beweisen für unsere Sicherheitspraktiken fragen. Dies ist eine durchaus vernünftige Anfrage, weil:

  1. Schlampige Sicherheit in Prod gefährdet ihre Daten. Siehe: Equifax-Verletzung von 2017 .
  2. Schlampige Sicherheit in der Entwicklung führt dazu, dass Entwickler schlampige Produkte schreiben. In Wirklichkeit muss die Einstellung, dass Sicherheit wichtig ist, vom Management kommen, um Entwicklern Sicherheitstrainings und Zeit für ordnungsgemäße Codeüberprüfungen zu geben, und die Bereitschaft, Sicherheitslücken vorrangig vor Kundenfunktionen zu beheben. Das Zulassen schlampiger Praktiken wie ist ein Beweis dafür, dass die Unternehmenskultur die Sicherheit nicht fördert.
  3. Schlampige Sicherheitspraktiken in der IT führen zu Viren im Netzwerk, die zu Viren im Code führen können. Siehe der berühmte Linux-Backdoor-Versuch von 20 , bei dem jemand elektronisch in das Backup-Code-Repository eingebrochen ist und eine Änderung des böswilligen Codes eingefügt hat, in der Hoffnung, dass er schließlich in das Haupt-Repo integriert wird.

Ist dies also eine Entscheidung, von der Sie stolz wären, einem Kunden davon zu erzählen?


Fazit: Das Prinzip der geringsten Privilegien ist eines der grundlegendsten Prinzipien der sicheren Codierung. Diese Denkweise sollte Teil jedes Softwareentwicklungsprozesses sein. Es geht darum, die Frage "Ist es notwendig, unsere Sicherheit so zu schwächen?" Zu stellen, anstatt "Kann jemand beweisen, dass dies gefährlich ist?". Die Hacker sind immer schlauer als Sie.

Natürlich, wenn chmod 777 ist aus irgendeinem Grund notwendig, dann wird es das geringste Privileg, und es könnte eine legitime Sicherheitsdiskussion geben, die hier zu führen ist, aber es klingt so, als gäbe es keine; Das ist nur Faulheit. Das gibt mir kein Vertrauen, dass das Prinzip der geringsten Berechtigung im Produkt selbst befolgt wird, z. B. wie Daten gespeichert werden, wie viele zusätzliche Daten von API-Aufrufen zurückgegeben werden, welche Informationen protokolliert werden oder wo auch immer das Prinzip der geringsten Berechtigung gilt relevant für Ihr Produkt.

26
Mike Ounsworth

Sofern für das Programm keine Schreibberechtigungen erforderlich sind, bin ich verwirrt darüber, warum Ihr Mitarbeiter chmod -R 777 /opt/path/to/shared/folder Verwendet hat, wenn chmod -R 775 /opt/path/to/shared/folder Lese- und Ausführungsberechtigungen weiterhin zulässt und den gewünschten Zugriff erzielt.

Vorausgesetzt, Ihre Teammitglieder sind die einzigen, die Zugriff auf den Server haben, und Sie vertrauen ihnen. Ein globaler Schreibzugriff ist nicht unbedingt eine schlechte Sache. Der Zweck besteht jedoch auch darin, zu verhindern, dass böswillige oder unerwünschte Programme die Dateien ändern oder löschen. Ransomware könnte ein Beispiel sein, das von Alice mit Benutzerberechtigungen ausgeführt wird.

  • / home/alice/--- (drwxrwxrwx alice alice)
  • / home/bob/--- (drwxrwx --- bob bob)

Für das obige Szenario würde die von Alice ausgeführte Ransomware alle Dateien verschlüsseln und überschreiben, auf die sie Schreibzugriff haben muss. Vorausgesetzt, Alice gehört nicht zur Gruppe bob und /home/bob/ Hat kein globales rwx Alice hat Kein Zugriff. Wenn Bob die Ransomware jedoch mit Benutzerberechtigungen ausführen soll, verfügt Bob über rwx Berechtigungen, da /home/alice/ Globale rwx Berechtigungen verwendet. Jetzt werden sowohl Alice als auch Bobs Home-Verzeichnisse von der Ransomware verschlüsselt.

Das Hinzufügen von Benutzern zu einer Gruppe ist ganz einfach, Linux: Benutzer zur Gruppe hinzufügen (primär/sekundär/neu/vorhanden) . Dadurch wird der Benutzername alice zur Gruppe bob hinzugefügt. Chown -R bob:bob Wobei user:group Das Verzeichnis rekursiv besitzt. chmod -R 750 Liefert rekursiv rwxr-x--- Berechtigungen, sodass Alice im Verzeichnis /home/bob/ Lesen und ausführen kann, aber nicht schreiben kann.

  • Sudo adduser alice bob
  • Sudo chown -R bob:bob /home/bob/
  • Sudo chmod -R 750 /home/bob/

Das Prinzip des geringsten Zugriffs besteht hauptsächlich darin, sich vor böswilligen Benutzern zu schützen. Schadprogramme sind jedoch auch ein sehr ernstes Problem. Aus diesem Grund ist globales Lesen, Schreiben und Ausführen zusammen ------rwx Ein sehr schlechtes Sicherheitsprinzip. Diese Idee wird durch Hinzufügen von alice zur Gruppe bob erreicht. Jetzt hat der Benutzer alice die Berechtigung r-x Für /home/bob/, Während andere Benutzer außerhalb der Gruppe bob dies nicht können, außer root. Wenn Bob Dateien für Alice freigeben möchte, aber keinen Gruppenzugriff für Alice wünscht, kann eine neue Gruppe namens AB erstellt werden, in der Alice und Bob in der Gruppe sind. Nun könnte ein Verzeichnis /opt/AB_share/ (rwxrwx---) erstellt und die obigen Befehle angewendet werden. Nur diejenigen innerhalb der Gruppe AB hätten Zugriff.

7
safesploit