Warum verlangen manche Software (Forum, Shop) 777'er Rechte

[Alexander (HH)]

Moin Moin!

bei 777 könnten ja wie bereits erwähnt auch other (also jeder von worldwide einfach in dem verzeichnis dateien speichern/ändern usw. ne?)

nur, wie würde das dann aussehen?

Mißverständnis: die letzte oktale Stelle des Mode ist nicht "world", schon gar nicht "worldwide", sondern "others". Also lokale(!) User, die weder Dateieigentümer noch Mitglied in der der Datei zugeordneten Gruppe sind.

ls -l
-rw-r-----  1 victim users        42 2010-06-12 16:11 example.txt
-rwxrwxrwx  1 victim users      5599 2011-01-05 17:14 storage.xml

Die Datei example.txt hat den Mode 640 (oktal), das bedeutet, dass nur der User victim sie schreiben kann, der User joe und alle Mitglieder der Gruppe users können sie lesen, der Rest kann weder schreiben noch lesen noch ausführen. (Mit Ausnahme des allmächtigen root, für den die Berechtigungen nicht gelten, weil er sich ohnehin alle Rechte verschaffen kann, die er haben will.)

Die Datei storage.xml hat den Mode 777 (oktal), jeder kann lesen, schreiben und sogar ausführen, was bei XML typischerweise völliger Mumpitz ist. Der User evil aus der Gruppe badboys kann also den Inhalt von storage.xml beliebig ändern, auch wenn victim das eigentlich gar nicht will.

Das heißt aber noch lange nicht, dass jeder Mensch auf der Welt die storage.xml sehen oder ändern kann, denn man braucht minimal einen Account auf dem System, oder einen von außen steuerbaren Prozess, sei es ein NFS-Daemon, Samba, FTP, oder schlicht PHP oder ein CGI unter dem Account des Webservers.

So, und nun zu Massen-Hostern. Fangen wir mit einem gar nicht so massigen Hoster an, der hat exakt zwei Kunden victim und evil. Damit die beiden sich möglichst nicht gegenseitig in die Quere kommen, legt er für jeden der beiden eine eigene Gruppe an, wie das bei vielen Linuxen üblich ist. Beide können CGIs laufen lassen, können sich aber nicht auf dem Server einloggen (außer per FTP). Der Webserver läuft ebenfalls unter einem eigenen User wwwrun, mit der Gruppe wwwrun.

ls -l
-rwxr-xr-x  1 victim victim       42 2010-06-12 16:11 example.cgi
-rwxrwxrwx  1 victim victim     5599 2011-01-05 17:14 storage.xml
-rw-rw-rw-  1 victim victim      876 2011-01-06 00:05 secrets.xml
-rw-r-----  1 victim victim   118765 2011-02-03 09:43 data.db
-rw-------  1 victim victim       63 2011-01-04 13:15 geheim.txt

evil kommt nun irgendwie an dieses Verzeichnislisting, sei es, weil der Hoster die Verzeichnisrechte nicht weit genug eingeschränkt hat oder weil das die dokumentierte Standard-Einstellung von example.cgi ist.

Und weil der Webhoster nicht der cleverste ist ("wir machen das seit 1990 so!"), laufen *alle* CGIs unter dem Account des Webservers, wwwrun. (Ob CGI oder PHP ist völlig egal, ich nehme einfach mal CGIs an.)

evil lädt nun ein eigenes CGI hoch, dass den Namen des Verzeichnisses von victim rät (/etc/passwd lesen, stumpf /home/$username/public_html annehmen, ...) und -- innerhalb der Grenzen, die die Unix-Dateirechte setzen -- Dateien manipulieren kann. Alle Aktionen von evil laufen dann "über Bande" unter dem Account des Webservers, wwwrun, einfach weil evil sein CGI in seinem Webbrowser aufruft.

example.cgi mit Mode 755 ist erst einmal relativ sicher, evil alias wwwrun kann zwar den Source Code bzw. den Inhalt des Binärfiles auslesen, aber nicht ändern, dafür fehlt das w-Bit für others. Damit kann evil schon einmal das gesamte CGI auf Lücken abklopfen.

secrets.xml mit Mode 666 ist ein leichtes Opfer, wwwrun ist weder Eigentümer noch in der victim-Gruppe, aber die Datei erlaubt ja auch für alle anderen User Lesen und Schreiben. evil hat damit volle Kontrolle über diese Datei.

storage.xml mit Mode 777 ist ein genauso leichtes Opfer. Und um es noch schlimmer zu machen, ist die Datei ausführbar, ein ausreichend schlecht konfigurierter Webserver würde die Datei tatsächlich als CGI ausführen. Ob die Datei-Extension nun .xml, .rhababerquark oder .cgi ist, ist dem Unix-Derivat vollkommen egal, Dateien mit einem x-Bit werden ausgeführt.

geheim.txt ist tatsächlich für evil nicht zu erreichen, weil wirklich nur victim und root Zugriff auf diese Datei haben. Auch wwwrun, der Webserver, kann nichts mit der Datei anfangen.

data.db ist ebenso wenig erreichbar, aus den gleichen Gründen.

Die Lösung dieses "Spiels über Bande" ist, Programmcode jedes Users unter dessen Account ausführen, und nicht unter einem Sammel-Account wie wwwrun, Stichwort suEXEC.

Dann sieht die Situation etwas anders aus, denn der von evil hochgeladene Programmcode läuft nicht mehr als wwwrun, sondern als evil. Der von victim hochgeladene Programmcode läuft analog als victim, nicht mehr als wwwrun.

example.cgi ist immer noch für evil les- und damit analysierbar. Besser wäre Mode 0700 (-rwx------).

secrets.xml ist immer noch für evil kontrollierbar.

storage.xml ebenso. Und was noch schlimmer ist: Es ist ausführbar. Eine Lücke in example.cgi, die dazu führt, dass storage.xml als externes Programm ausgeführt statt nur gelesen wird, sorgt dafür, dass evil beliebigen Programmcode unter dem Account von victim ausführen kann.

geheim.txt ist nicht länger sicher vor dem Webserver, denn example.cgi läuft unter dem Account victim und hat damit Lese- und Schreibrechte auf diese Datei. Allerdings hat evil ohne Lücken in example.cgi keine Chance, auf diese Datei zuzugreifen, weil seine CGIs unter dem Account evil laufen, der fällt in die Kategorie others und hat keinerlei Rechte an dieser Datei.

Für data.db gilt das gleiche.

Was, wenn nun alle User in einer users-Gruppe stecken, statt in individuellen Gruppen?

Keine großartigen Unterschiede für example.cgi, secrets.xml, storage.xml, geheim.txt.

Aber data.db ist plötzlich für alle User lesbar, auch für evil, selbst wenn sein CGI unter dem Benutzer-Account evil läuft.

Welcher Mode ist also der richtige?

Für Dateien:

644 (-rw-r--r--) für Dateien, die die ganze Welt sehen darf. HTML-Dateien, Bilder, Texte.
444 (-r--r--r--) analog, jedoch mit Schutz gegen versehentliches Überschreiben
600 (-rw-------) für "geheime" Dateien, z.B. Konfigurationsdatei mit dem Passwort zur Datenbank, oder auch für eine Flat-File-Datenbank.
400 (-rw-------) analog, jedoch mit Schutz gegen versehentliches Überschreiben

Ungerade Ziffern (das x-Bit) haben bei Dateien nichts verloren!

Für Programme:

755 (-rwxr-xr-x) für Programme, die die ganze Welt sehen darf. Das sind eigentlich nur die "ab Werk" installierten Programme des Betriebssystems.
711 (-rwx--x--x) für Programme, deren Innenleben nicht jeder sehen soll. Haken: Das funktioniert nicht für Scripte, denn sobald der Script-Interpreter läuft, muß er das Programm lesen können. Für Scripte also zähneknirschend 755.
700 (-rwx------) für Programme, die wirklich nur der Eigentümer ausführen können soll -- und der Webserver, wenn suEXEC im Spiel ist
Analog 555, 511 und 500 für einen Schutz gegen versehentliches Überschreiben

Gerade Ziffern (fehlendes x-Bit) haben bei Programmen nichts verloren.

Für Verzeichnisse:

Hier meint "x" nicht ausführen, sondern "cross", sprich: betreten

755 ist der Normalfall, jeder darf den Verzeichnisinhalt lesen, jeder darf ins Verzeichnis hinein.
700 verrammelt das Verzeichnis, nur der Eigentümer darf lesen/schreiben und überhaupt hinein
711 ist die etwas lockerere Variante von 700: Hinein darf jeder, aber das Verzeichnislisting darf nur der Eigentümer sehen.

Gerade Ziffern (fehlendes x-Bit) haben auch bei Verzeichnissen nichts verloren.

Diese Modi funktionieren nicht wie erwartet, wenn der Hoster nicht fein säuberlich die Programme der Benutzer unter deren Account laufen läßt, sondern mit einem Sammelaccount arbeitet. Das ist aber IMHO ein Grund, den Hoster zu wechseln, denn unter einem Sammelaccount kann man einfach nicht sicher hosten.

Dann gibt es auch noch wilde Konstrukte, bei denen zwar CGIs mit suEXEC laufen, PHP aber gnadenlos für alle User den selben Sammelaccount benutzt. Auch das ist IMHO ein Grund, den Hoster zu wechseln. PHP funktioniert nur auf einem getrennten Server (virtuell, managed oder Root) innerhalb des Webservers, ansonsten muß man sich damit behelfen, PHP per suEXEC als CGI laufen zu lassen, und das bremst ganz fürchterlich. Alles Gefrickel innerhalb von PHP, die Unix-Rechteverwaltung nachzubauen, funktioniert nicht.

Alexander