chmod für das /tmp und /files

Generell ist mehr Sicherheit immer vorzuziehen und wenn die gennanten Verzeichnisse auch ohne Probleme mit 766 laufen, soll es mir recht sein.
Ich werde das nachher mal bei mir entsprechend einstellen und testen.

Danke Dir für die Info Holger!

Wenn du die chmod der beiden verzeichnisse auf 755 setzt wäre das meines Erachtens sogar noch besser, jedoch kommt es dann bei manchen Drupal-Installationen zu Fehlermeldungen das die Verzeichnisse nicht beschreibbar seien. Da hilft wohl nur Testen ;-)

Soweit ich es beurteilen kann bringt chmod 777 zwar immer sofort eine lauffähige Routine, jedoch ist mit dieser Einstellung die Sicherheit auch geringer. Deshalb meine Überlegung.

mfg holger

drupal experience http://cms.stnetwork.de

Projekte: www.ebec.net | www.stnetwork.de

Zunächst muss man das Gefahrenpotential sehen. chmod 777 erlaubt es jedem, den Inhalt des Verzeichnisses zu sehen und zu verändern. chmod 755 erlaubt nur dem Eigentümer Änderungen, aber alle anderen dürfen es lesen. Die beste Variante wäre demnach chmod 700 (Eigentümer darf alles, andere gar nichts).

Die beste Einstellung führt aber auf Servern von Standard-Hostern regelmäßig zu Problemen. Warum?

Der Kunde erhält in der Regel einen FTP- oder SFTP-Zugang. Der Hoster ordnet dem Kunden einen Unix-Benutzer zu. Je nach Sicherheitsempfinden des Hosters ist der Benutzer einer Gruppe aller Benutzer oder einer eigenen Gruppe zugeordnet.

Der Web-Server selbst läuft oft als Benutzer www und gehört der Gruppe wwwrun an. Wenn PHP als Apache-Modul (mod_php4 oder mod_php4) verwendet wird, dann läuft PHP in dem Kontext dieses Benutzers. Sicherheitsorientierte Hoster nutzen suPHP in einer chroot-Umgebung; PHP läuft dann im Idealfall im Kontext des FTP-Nutzers. Es liegt nahe, dass der Web-Server auf die Dateien zugreifen können sollte.

Demnach haben wir mehrere Möglichkeiten, aus denen sich unterschiedliche chmod-Werte ergeben:

• Benutzer: kunde.grosse_gruppe; PHP: www.wwwrun. Wenn Kunde und Web-Server zusätzlich einer gemeinsamen Gruppe angehören, reicht chmod 770, ansonsten 777.
• Benutzer kunde.eigene_gruppe; PHP: www.wwwrun. Wie vorstehend.
• Benutzer: kunde.gruppe; PHP: kunde.gruppe: In diesem Fall kann ein Verzeichnis, welches keine HTML-Dateien enthält, sondern nur PHP-Dateien, auf die nicht direkt zugegriffen wird (typischerweise includes/ und database/) mit chmod 700 versehen werden, die anderen Verzeichnisse sollten je nach Notwendigkeit, Dateien dort verändern zu können, chmod 770 oder 760 erhalten.

Bleibt abschließend die Frage, welchen Sinn es haben könnte. Im Normalfall benötigt man ein Skript, um Dateien auf den Server zu speichern. Diese werden in aller Regel auch nicht ausgeführt, sondern nur angezeigt (Images, PDF). Hier obliegt es dem Skript, XSS und ähnliche Angriffe zu unterbinden. chmod ist hier wenig hilfreich, da es nur die Zugriffe der Software auf dem Server organisiert, nicht aber die Zugriffe von außen. Die obige Darstellung zeigt auch deutlich, wie wichtig eine vernünftige Strategie bei der Anlage der Kunden-Konten ist. Die früher oft verwendete Methode, alles in einer großen Gruppe zu halten, erlaubt es jedem Kunden auf jeden Web-Space der anderen Kunden zuzugreifen, die auf derselben physikalischen Maschine liegen. Deshalb wurde bei PHP die open_basedir-Funktionalität implementiert, die den Zugriff auf andere Verzeichnisbäume unterbindet.

Eine optimale Sicherheit gibt es nicht, aber eine vernünftige Infrastruktur wäre suPHP mit einer chroot-Umgebung, wobei PHP im Kontext des FTP-Kontos läuft. Noch besser ist natürlich ein eigener Server, den man nicht mit fremden Kunden teilen muss.

Die meisten Drupal-Nutzer haben jedoch keinen eigenen Server sondern nutzen herkömmliches Shared Webhosting. Abgesehen davon übersteigt die Administration eines eigenen Servers bei vielen auch das Wissenspotenzial erheblich ;-)

Um zu dem eigentlichen Thread zurück zu kommen: Welche CHMOD für /tmp und /files haltet ihr denn für sinnvoll und welche Erfahrungen habt ihr damit?

mfg holger

drupal experience http://cms.stnetwork.de

Projekte: www.ebec.net | www.stnetwork.de

Ein chmod 766 ist grober Unfug - das erlaubt absolut allen, blind in das Verzeichnis zu schreiben, aber nur dem Eigner, das Verzeichnis und seine Inhalte zu lesen. Die Risiken (Eintragungen durch fremden Benutzer mit Shellaccount) sind dieselben wie bei Mode 777, bloß ist die Administrierbarkeit so schlecht wie bei Mode 700, und wenn das Verzeichnis nicht der UID des Webservers gehört, ist es für diesen unlesbar...

Sinnvoll ist eher, das Verzeichnis setgid und sticky als Mode 3775 unter der UID des Webservers und mit einer auf die Administratoren beschränkten Gruppe (oder umgekehrt) anzulegen.

Gruß Sevo

Richtig, mein Fehler (hatte normale Dateien im Hinterkopf). Allerdings ändert die falsche Zahl nichts an der Aussage, dass die Relevanz der Einstellung nur das Verhalten der auf dem Server ausgeführten Programme beeinflusst (eben die Shell, den Web-Server oder CGI-Skripte).

Wobei diese Aufgabe dem Server-Admin zufällt, nicht dem Web-Hoster-Kunden. Und wenn wir beim Server-Admin sind, dann dürfte suPHP in einer chroot-Umgebung derzeit die sicherste Lösung darstellen.

Im Kontext des Threads muss wohl auch noch zwischen /tmp und files/ unterschieden werden. Ersteres sollte vom Server-Admin vernünftig konfiguriert werden. Bei dem files-Verzeichnis handelt es sich schlicht um Uploads durch Drupal. Hier obliegt es Drupal, die Daten zu verwalten, und vor allem die Berechtigung für Uploads peinlichst genau zu prüfen.

Aber setze ich die chmod auf 755 bringt mir das Drupal System die Meldung *Das Verzeichnis files ist nicht beschreibbar*

Welche CHMOD setzt ihr denn da nun für /files und /tmp ein?

Sicherheit ist wichtig, klar ... aber das System muss ja auch laufen.

mfg holger

drupal experience http://cms.stnetwork.de

Projekte: www.ebec.net | www.stnetwork.de

Die Frage hängt davon ab, ob auf Deinem Hoster Web-Server und PHP sowie FTP in verschiedenen Benutzer- und Gruppenkontexten laufen. Im Regelfall ist das zu bejahen, so dass Du um eine Freigabe für alle kaum herumkommst. Wenn 755 bzw. 750 nicht funktioniert, dann wäre 770 vor 775 und vor 777 zu prüfen.

Unabhängig davon sollte die Erlaubnis eines Uploads sehr restriktiv gehandhabt werden (gleiches gilt für die erlaubten HTML-Tags bei den Filtern).

Kann man 'files' nicht auch außerhalb des öffentlich-zugänglichen Bereiches im eigenen Account anlegen?
Das würde doch auch noch zusätzliche Sicherheit bringen.

Gruß, Frank

Wirkliche Sicherheit hat man erst, wenn man den Stecker zieht, was Du damit tätest, da die Dateien im Ordner files/ ja auch angesehen bzw. herruntergeladen werden können sollen.

Die Sache ist ja die, dass das Verzeichnis ja von außen nicht zu erreichen ist, intern aber schon.
Wenn die dort drin abgelegten Dateien mit Hilfe von Drupal hochgeladen werden (Filemanger) und via Drupal auch ausgeliefert werden, sind sie dennoch nutzbar.

Ich muß mir die Variante mal ansehen, da ich sie noch nicht getestet habe, kenne es aber von anderen Scripten, die es ähnlich machen.

Gruß, Frank

Das kannst Du auch mit der .htaccess erreichen.