Nachdem ich jedoch einiges darüber nachgedacht habe, kann ich nicht sagen, warum freigegebener ausführbarer Code auf einem internen Server keine 777-Berechtigungen haben sollte.
Weil Sie nicht nur jedem Benutzer vertrauen – was auf einem internen Server sinnvoll sein könnte, auf dem „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 "nobody" und "nogroup" laufen. Alle Arten von Prozessen, die von einem Angreifer genutzt werden könnten, um seinen Zugriff zu erlangen oder zu erweitern.
Denn wenn Sie in der internen Entwicklung so schlampig sind, wird jemand in einem Produktions- oder Kundensystem so schlampig sein, weil "wir es intern so behoben haben".
Weil ein Angreifer Freude daran haben wird, dieses kleine System zu finden, das nur intern und nicht wichtig oder geschützt ist, Schwachstellen wie beschreibbare Webanwendungsdateien zu erkennen, sie zu nutzen, um in das System einzudringen und es auszunutzen, um irgendwohin zu gelangen. Ich wette, die Passwörter, die die Leute auf diesem System verwenden, funktionieren auch auf anderen, wertvolleren internen Systemen. Vielleicht benutzt ihr ja auch serverübergreifend dasselbe Root-Passwort? Es macht immer Spaß, das zu finden.
Ich schließe mich @gowenfawr an und sage, dass das Züchten besserer Schimpansen hier ein Ziel für sich ist. (Jetzt werde ich wild über Ihre Unternehmenskultur extrapolieren)
In meiner Softwareentwicklungsfirma sehen wir einen zunehmenden Trend von Kunden, die nach Nachweisen unserer Sicherheitspraktiken nicht nur in Produktionsumgebungen, sondern auch in unserem Entwicklungsprozess und in der Unternehmens-IT im Allgemeinen fragen. Dies ist eine vollkommen vernünftige Anfrage, weil:
- Nachlässige Sicherheit in der Produktion gefährdet ihre Daten. Siehe:Equifax-Verletzung von 2017.
- Nachlässige Sicherheit in der Entwicklung führt dazu, dass Entwickler nachlässige Produkte schreiben. Tatsächlich muss die Einstellung, dass Sicherheit wichtig ist, vom Management kommen, um den Entwicklern Sicherheitsschulungen und Zeit für ordnungsgemäße Codeüberprüfungen sowie die Bereitschaft zu geben, der Behebung von Sicherheitslücken Vorrang vor Kundenfunktionen zu geben. Das Zulassen schlampiger Praktiken wie ist ein Beweis dafür, dass die Unternehmenskultur die Sicherheit nicht fördert.
- Nachlässige Sicherheitspraktiken in der IT führen zu Viren im Netzwerk, die zu Viren im Code führen können. Sehen Sie sich den berühmten Linux-Backdoor-Versuch von 2003 an, bei dem jemand elektronisch in das Backup-Code-Repository einbrach und eine böswillige Codeänderung einfügte, in der Hoffnung, dass sie schließlich in das Haupt-Repository integriert würde.
Ist das also eine Entscheidung, die Sie einem Kunden mit Stolz mitteilen würden?
Fazit: Das Prinzip der geringsten Rechte ist eines der grundlegendsten Prinzipien für sichere Codierung. Es ist eine Denkweise, die Teil jedes Softwareentwicklungsprozesses sein sollte. Es geht darum, die Frage zu stellen „Ist es notwendig, unsere Sicherheit so zu schwächen?“ und nicht „Kann jemand beweisen, dass dies gefährlich ist?“. Die Hacker sind immer klüger als Sie.
Natürlich wenn chmod 777 aus irgendeinem Grund notwendig ist, dann wird es zum geringsten Privileg, und es könnte hier eine legitime Sicherheitsdiskussion geben, aber es hört sich so an, als ob es keine gibt; das ist einfach Faulheit. Das gibt mir kein Vertrauen, dass das Prinzip der geringsten Rechte 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 Rechte gilt relevant für Ihr Produkt.
Wenn das Programm keine Schreibberechtigungen erfordert, bin ich verwirrt darüber, warum Ihr Kollege chmod -R 777 /opt/path/to/shared/folder verwendet hat wenn chmod -R 775 /opt/path/to/shared/folder würde dennoch Lese- und Ausführungsberechtigungen zulassen und den gewünschten Zugriff erreichen.
Vorausgesetzt, Ihre Teammitglieder sind die einzigen, die Zugriff auf den Server haben, und Sie vertrauen ihnen. Globalen Schreibzugriff zu haben ist nicht unbedingt eine schlechte Sache. Der Zweck besteht jedoch darin, auch zu verhindern, dass bösartige oder betrügerische Programme die Dateien ändern oder löschen. Ein Beispiel könnte Ransomware sein, die von Alice mit Benutzerrechten 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 hat. Da Alice nicht gehören zur Gruppe bob und /home/bob/ hat kein globales rwx Alice hat keinen Zugriff. Wenn Bob die Ransomware jedoch mit Benutzerberechtigungen ausführen sollte, hat Bob rwx Berechtigungen, weil /home/alice/ verwendet globales rwx Berechtigungen. Also, jetzt werden die Privatverzeichnisse von Alice und Bob von der Ransomware verschlüsselt.
Das Hinzufügen von Benutzern zu einer Gruppe ist ganz einfach, Linux:Benutzer zu Gruppe hinzufügen (Primär/Sekundär/Neu/Vorhanden). Dadurch wird der Benutzername hinzugefügt:alice , zum bob Gruppe. Chown -R bob:bob wobei user:group besitzt rekursiv das Verzeichnis. chmod -R 750 liefert rekursiv rwxr-x--- Berechtigungen, damit Alice in /home/bob/ lesen und ausführen kann Verzeichnis, kann aber nicht schreiben.
sudo adduser alice bobsudo chown -R bob:bob /home/bob/sudo chmod -R 750 /home/bob/
Das Prinzip des geringsten Zugriffs dient hauptsächlich dem Schutz vor böswilligen Benutzern. Schadprogramme sind jedoch auch ein sehr ernstes Problem. Deshalb zusammen ------rwx globales Lesen, Schreiben und Ausführen ist ein sehr schlechtes Sicherheitsprinzip. Diese Idee wird durch Hinzufügen von alice umgesetzt zum bob Gruppe. Jetzt der Benutzer alice hat r-x Berechtigungen für /home/bob/ während andere Benutzer außerhalb von bob sind Gruppe nicht, außer root. Ebenso, wenn Bob Dateien mit Alice teilen wollte, Alice aber keinen Gruppenzugriff haben möchte, eine neue Gruppe namens AB wo Alice und Bob in der Gruppe sind erstellt werden könnte. Jetzt ein Verzeichnis /opt/AB_share/ (rwxrwx---) erstellt und die obigen Befehle angewendet werden. Nur die innerhalb des AB Gruppe Zugriff hätte.