Hi!
Noch ein paar Ergänzungen:
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.
Wenn er für das Verzeichnis ein w-Bit hat, kann er sich die Dateirechte verschaffen. Dateirechte ändern ist nämlich eine Schreiboperation im Verzeichnis. Man muss also nicht nur die Dateirechte und Besitzverhältnisse betrachten, sondern auch die des Verzeichnisses, in dem etwas liegt. Eigentlich sogar bis hoch zur Wurzel, denn von übergeordnet nach weiter unten durchgehend kann man sich ja auch die Rechte verschaffen.
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.
Der Apache führt sie aber nur dann aus, wenn sie im CGI-Verzeichnis liegen. Das ist ein normales Verzeichnis, das mit Konfigurationsdirektiven (ScriptAlias) für die CGI-Ausführung freigegeben ist. Allerdings ist der Apache nicht der einzige, der sich für das x-Bit interessiert. Über das Betriebssystem gestartet ist es egal, in welchen Verzeichnis die x-Bit-Datei liegt. Deshalb ist das x-Bit auch außerhalb des ScriptAlias nicht ungefährlich. PHP-Scripte sind aber nicht unbedingt mit CGI-Scripten gleichzusetzen, aber dazu komme ich gleich noch.
Welcher Mode ist also der richtige?
Für Dateien:
[...]
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
Tippfehler, in der 400er Zeile muss das -r-------- heißen.
Ungerade Ziffern (das x-Bit) haben bei Dateien nichts verloren!
Für Programme:
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.
Wenn der Script-Interpreter PHP heißt, dann braucht der kein x-Bit. Ausnahme sind Scripts, die mit einer Shebang-Zeile beginnen und direkt über ihren Dateinamen aufgerufen werden. In der Shebang-Zeile steht dann der Pfad zum zu verwendenden Script-Interpreter.
Auch andere nicht direkt aufgerufenen Scripts benötigen kein x-Bit, also alles was à la
php script.php
aufgerufen wird, muss vom Script-Interpreter (hier die CLI-Version von php) nur gelesen werden können.
Gerade Ziffern (fehlendes x-Bit) haben bei Programmen nichts verloren.
Gerade Ziffern (fehlendes x-Bit) haben auch bei Verzeichnissen nichts verloren.
Verloren würde ich das nicht unbedingt bezeichnen. Es schadet nichts, nur die Funktionalität ist dann nicht da.
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.
Dagegen hatte man bei PHP den Safe Mode erfunden, der das Problem der nicht erfolgten Trennung seitens des Systembetreibers lösen sollte. Doch das war aus Sicherheitssicht nicht der richtige Ansatz und machte mehr Probleme als er löste. Der Safe Mode ist aber im Grunde genommen Geschichte. Er existiert noch in der freien Wildbahn, wenn er jedoch angetroffen wird, zeugt das nur davon, dass der Administrator entweder ein Geizhals war (Apache-Modul mit vielen Usern ist performanter als jedes Script unter eigener Benutzerkennung separat zu starten) oder von Sicherheit nicht die allerbeste Ahnung hatte.
Alles Gefrickel innerhalb von PHP, die Unix-Rechteverwaltung nachzubauen, funktioniert nicht.
Genau, damit meintest du den Safe Mode.
Lo!