PHP in Multi-User-Umgebungen

[arty]

Dieses Dokument ist dazu da, auf die Probleme von mod_php bei mehreren Usern hinzuweisen und verschiedene Lösungswege aufzuzeigen.

1. PHP als Apache-Modul und als CGI-Version
PHP kann man auf zwei Arten in sein System einbinden, als Apache-Modul (mod_php) und als CGI-Version.
Wenn PHP als Modul läuft, wird es beim Starten des Apache einmal geladen und bleibt anschließend gestartet. Das Modul läuft unter den Benutzerrechten des Apache-Users, also bei Debian z.B. unter www-data. Wenn man nun eine Datenbankverbindung öffnen möchte, so muss der Apache-User dazu das recht haben. Und der Apache-User benötigt auch Schreibrechte in den Benutzerverzeichnissen der einzelnen User, um z.B. Daten ins Dateisystem zu schreiben.
PHP als CGI läuft hingegen unter dem jeweiligen Benutzerrechten, in /home/user42 als user42. Bei jedem Aufruf einer PHP-Seite muss das CGI allerdings erst geladen und dann ausgeführt werden, deswegen funktionieren z.B. auch keine persistenten Datenbankverbindungen mit PHP-CGI und auch keine Authentifizierung über HTTP-Auth.

2. PHP und Sicherheit
Zuerst sollte man sich im PHP Manual die Seiten über die Sicherheit durchlesen: http://de3.php.net/manual/de/security.php
Kurz gesagt, PHP bekommt man bei Multi-User-Umgebungen nicht durch den Einsatz des Safe-Mode sicher, sondern nur dadurch, dass man PHP als CGI über suExec oder suPHP laufen lässt und die User in einer chroot-Umgebung lässt.

3. PHP und das Dateisystem
Beim Einsatz von PHP und Confixx in der Grundkonfiguration der 1&1 Rootserver kann PHP keine Dateien ins Dateisystem schreiben. Der Grund hierfür ist der aktivierte Safe-Mode und die Tatsache, dass der Benutzer des Webservers keine Schreibrechte in dem Verzeichnis des Users hat. Am einfachsten ist es, auf PHP als CGI umzustellen, da dann wie bereits beschrieben, PHP unter den jewiligen Userrechten läuft und somit dieser Benutzer auch schreiben darf.
Will man weiterhin mod_php nutzen, so muss man dem Apache Schreibrechte in dem jeweiligen Verzeichnis gewähren.
Hinweis: ein chmod 777 ist das Dümmste, was man machen kann und sollte immer unterlassen werden!

[captaincrunch]

Auch wenn ich nichts von PHP verstehe :

Hinweis: ein chmod 777 ist das Dümmste, was man machen kann und sollte immer unterlassen werden!

Danke ! Diesen Satz sollten wir vielleicht in jedem Forum hier pinnen ... ;)

[nyxus]

Hinweis: ein chmod 777 ist das Dümmste, was man machen kann und sollte immer unterlassen werden!

Danke ! Diesen Satz sollten wir vielleicht in jedem Forum hier pinnen ... ;)

Hast Du konkrete Beispiele wie man das ausnützen kann? Ich habe da evtl. auch so ein "Problemscript" ...

[wgot]

Hallo,

und wie geht das: dem Apache Schreibrechte in dem Verzeichnis geben?

Gruß, Wolfgang

[mstuebner]

und wie geht das: dem Apache Schreibrechte in dem Verzeichnis geben?

Zum Beispiel indem Du den Apacheuser in die selbe Gruppe steckst wie den User, und dann der Gruppe Schreibrechte gibst.

[darkspirit]

Wenn man nun eine Datenbankverbindung öffnen möchte, so muss der Apache-User dazu das recht haben.

Sicher? Also zumindest bei MySQL ist das ziemlich wurscht, unter welchem User das entsprechende Programm (z.b. Apache) läuft, dass die Verbindung aufbauen will, solange beim connecten der angegebene Username mit dem Passwort stimmt, oder verstehe ich da was falsch?

[captaincrunch]

Hast Du konkrete Beispiele wie man das ausnützen kann? Ich habe da evtl. auch so ein "Problemscript" ...

Jein. Ich denke mal, dass schon klar ist, dass man durch 777 (besonders lokal) je nach Konfiguration und Script mehr machen könnte, als einem zusteht.
Sofern du lokale User hast, hätten diese dadurch die Möglichkeit, das Script ihren Vorstellungen "anzupassen", was nicht gerade das sein muss, was dir mit diesem Script vorschwebt, und alleine das ist schon Risiko genug.

Konkrete "Beispiele" kann ich dir (ohne konkreten Fall) allerdings nicht aufzeigen, da für eine wirkliche "Bedrohung" natürlich gewisse Faktoren (Fähigkeit des Webmasters, Konfiguration des Webservers, das Script selbst, usw.) abhängt. Alleine die Tatsache, dass jeder sich am Script zu schaffen machen kann, sollte die Alarmglocken aber schon genug klingeln lassen.
Natürlich gibt's auch welche, die die Voraussetzungen geschaffen haben, dass eine solche Lücke nicht (oder nur schwer) auszunutzen ist, meine Aussage hier bezog sich aber ohnehin auf diejenigen, die ich hier lese, und die meinen, dass sie eine große Tat vollbracht haben, Scripte zum laufen zu bekommen, imdem sie (ohne auch nur an die Folgen zu denken) die Rechte auf 777 gesetzt haben.

[arty]

Hi,

Sicher? Also zumindest bei MySQL ist das ziemlich wurscht, unter welchem User das entsprechende Programm (z.b. Apache) läuft, dass die Verbindung aufbauen will, solange beim connecten der angegebene Username mit dem Passwort stimmt, oder verstehe ich da was falsch?

so stehts jedenfalls im PHP Manual: http://www.php.net/manual/de/security.apache.php

bye
arty

[darkspirit]

Hast Du konkrete Beispiele wie man das ausnützen kann? Ich habe da evtl. auch so ein "Problemscript" ...

Noch in Ergänzung zum Captain ein Beispiel:
Ein Admin baut sich ein Script zur Systemverwaltung und setzt dummerweise die Rechte auf 777. Wenn ein User weiß, dass dieses Script öfters von Root aufgerufen wird, könnte er eine kleine aber feine Zeile einfügen: "cat /etc/shadow > /home/user/passwd".. oder "rm -rf /" wenn er einen schlechten Tag hat.. es ist unwahrscheinlich, dass der Admin sich das Script vor jedem Durchlauf neu ansehen wird, sondern führt einfach den Code aus.. ;)
Bei PHP ist es bißchen weniger kritisch, da der Apache normalerweise ja nicht als Root läuft/laufen sollte und man die Config schon sehr verhunzen muss um das oben genannte zu ermöglichen. Das war also mehr ein generelles Beispiel zur 777-Problematik wie es bei Shell-Scripts vorkommen könnte..

@arty: Stimmt, steht da. Aber da steht auch "es sei denn diese Datenbank hat eine integrierte Zugriffskontrolle" und beim Paradebeispiel MySQL trifft das zumindest zu ;)

[[nix]pepe]

mich würd mal interessieren, wie ich an einem script, das auf 777 steht rumfummeln kann von aussen... oO

[nyxus]

Jein. Ich denke mal, dass schon klar ist, dass man durch 777 (besonders lokal) je nach Konfiguration und Script mehr machen könnte, als einem zusteht.
...

Noch in Ergänzung zum Captain ein Beispiel

danke für die Ausführungen. Für meine lokale Betrachtung komme ich dazu, daß ich mit dem Risiko dann leben kann (habe halt befürchtet, irgendeine Möglichkeit übersehen zu haben). Shell-User habe ich keine, und alles was die User können ist per FTP an ihre Verzeichnisse rankommen (über WebDAV denke ich gerade nach). Aber auf das Script und die Ordner mit den benötigten 777-Rechten hat außer mir erstmal kein User Zugriff. Insgesamt nicht schön, aber für mich gerade noch akzeptabel.

[captaincrunch]

... wobei du aber nicht außer Acht lassen solltest, wie das besagte Script programmiert ist, bzw. was genau es macht. Im schlimmsten Fall lassen sich Lücken so (leichter) ausnutzen, wobei derjenige dann immerhin die gleichen Rechte hat wie der Apache-User (was zwar auch nicht gerade viel ist, aber immerhin ein Anfang).

Stichworte hierzu : SQL-Injection, nicht vorgesehene Parameterübergabe, usw.

[wgot]

Hallo,

sind Ordner mit 777 auch ein Sicherheitsrisiko?

Falls ja:

Confixx legt als /home/www/webX/phptmp für jeden User einen Ordner mit 777 an. Vergrößere ich das Risiko, wenn ich einen daneben lege, z.B. /home/www/webX/data mit ebenfalls 777?

Gruß, Wolfgang

[darkspirit]

777 bei Ordnern bedeutet, dass jeder darin Dateien anlegen kann.. ist ebenfalls unschön, auch wenn mir jetzt konkret kein sicherheitskritisches Beispiel einfällt.. die Frage ist einfach, ob es solche Ordner überhaupt braucht. Ich sage nein ;)

[nyxus]

Stichworte hierzu : SQL-Injection, nicht vorgesehene Parameterübergabe, usw.

Ist ein einfaches Perl-Script mit "Text"-Datenbank. Zum Glück nichts mit SQL und Konsorten.

[wgot]

Hallo,

PHP (Modul, Safe-Mode on) soll Dateien anlegen. Ich hab alles mögliche ausprobiert mit verschiedenen Ordnerpositionen, Chmod und Chown. Ich find keine Lösung, außer dem Ordner 777 zu geben (die Dateien bleiben natürlich 644).

Gruß, Wolfgang

[dodolin]

PHP (Modul, Safe-Mode on) soll Dateien anlegen. Ich hab alles mögliche ausprobiert mit verschiedenen Ordnerpositionen, Chmod und Chown. Ich find keine Lösung, außer dem Ordner 777 zu geben (die Dateien bleiben natürlich 644).

Davon abgesehen, dass man deshalb ja auch PHP als CGI benutzen sollte, hatte doch mstuebner hierzu schon eine Lösung geschrieben:

und wie geht das: dem Apache Schreibrechte in dem Verzeichnis geben?

Zum Beispiel indem Du den Apacheuser in die selbe Gruppe steckst wie den User, und dann der Gruppe Schreibrechte gibst.

[wgot]

Hallo,

Davon abgesehen, dass man deshalb ja auch PHP als CGI benutzen sollte...

Die Frage, warum es php_mod dann überhaupt gibt und es standardmäßig installiert ist, kann ich mir ja wohl sparen.

Zum Beispiel indem Du den Apacheuser in die selbe Gruppe steckst wie den User, und dann der Gruppe Schreibrechte gibst.

Klingt gut, klappt nur nicht - oder ich bin zu blöd dazu:

usermod -Gftponly wwwrun
(alternativ über Yast, hab ich auch probiert)
und dann den Ordner auf 775.

Besitzer des Ordners ist webX, laß ich's dabei, kann fopen() die Datei nicht anlegen, änder ich den Besitzer auf wwwrun, meckert Safemode.

Dummguck, Wolfgang

[dodolin]

Die Frage, warum es php_mod dann überhaupt gibt

Weil es in Singleuserumgebungen geeigneter sein "kann" und dann bessere Performance bringt.

und es standardmäßig installiert ist, kann ich mir ja wohl sparen.

AFAIK wird z.B. bei 1&1 ein SuSE-Standardimage aufgespielt, die Frage musst du also an SuSE weiterreichen, warum die das in ihrer Distri per Default so drin haben...

Aber diese Frage kannst du beliebig erweitern: Viele, viele Dinge, die per Default in manchen Distris so an sind bzw. benutzt werden, sind sicherheitstechnisch zumindest sehr fragwürdig, mal vorsichtig ausgedrückt.

Wer einen Rootserver hat, sollte halt IMHO schon so erfahren sein, dass er das einschätzen kann, was gut ist und was nicht und sich nicht einfach blind auf irgendeine Default-Installation verlassen.

[arty]

Hiho,

mod_php ist sehr viel schneller als PHP als CGI und benötigt sehr viel weniger Speicher, da es ja nur einmal beim Start des Apache aufgerufen wird.

bye
arty

[impulz]

Also erstmal macht es keinen Sinn den Apache in eine gemeinsame Usergruppe (z.B. ftponly) zu stecken und dann Rechte auf die Gruppe zu vergeben, da dort ebenfalls alle anderen User drin sind, da kann auch gleich world-permissions geben.

Das ganze wuerde also erstmal nur anfangen Sinn zu machen wenn jeder User ne eigene Gruppe hat. Damit kann ich verhindern, dass andere User ueber CGI oder Shell ebenfalls Zugriff auf diese Dateien haben.
Mit mod_php endet der Sinn dann aber auch schon wieder, da jeder User mit den Rechten den Apaches herumfuhrwerken kann und es dann Latte is, ob die Datei 777 hat, oder 775 und der Apache Gruppenrechte hat.
Hier muss dann wieder mit OpenBaseDir rumgewerkelt werden.

Darum finde ich die Panikmache bei 777 in Verbindung mit PHP als Modul etwas uebertrieben. Die Sicherheitsrisiken entstehen dann naemlich nicht bei PHP, sondern bei anderen Sachen, wo User mit eigenen Rechten arbeiten. (CGIs i.e.)

[majortermi]

Also erstmal macht es keinen Sinn den Apache in eine gemeinsame Usergruppe (z.B. ftponly) zu stecken und dann Rechte auf die Gruppe zu vergeben, da dort ebenfalls alle anderen User drin sind, da kann auch gleich world-permissions geben.

Stimmt: Entweder ich setze den Apache eine Gruppe, in der sonst kein User ist, und setzte die Home-Verzeichnisse auf 0750 mit user.www (wobei www die Gruppe des Apaches ist) oder ich setze alle normalen User in eine Gruppe und setze dann die Home-Verzeichnisse auf 0705 mit user.group (wobei group die Gruppe der normalen User ist, in der sich aber nicht der Apache befindet). Darüber, was sinnvoller ist, kann man sicherlich streiten.

[dodolin]

Darüber, was sinnvoller ist, kann man sicherlich streiten.

Nein, da muss man nicht streiten: Auch auf die Gefahr hin mich zu wiederholen, sinnvoller ist PHP-CGI. :)

[majortermi]

Nein, da muss man nicht streiten: Auch auf die Gefahr hin mich zu wiederholen, sinnvoller ist PHP-CGI. :)

Davon rede ich doch :)
Auch wenn man PHP als CGI einsetzt, muss der Apache immer noch statische Seiten lesen können, aber andere Benutzer sollten das natürlich nicht können.

[dodolin]

muss der Apache immer noch statische Seiten lesen können, aber andere Benutzer sollten das natürlich nicht können.

Kannst du mir einen sinnigen Grund sagen, warum statische HTML-Seiten (d.h. also insbesondere sind da keine Passwörter für DBs drin oder so...), die für jeden per HTTP verfügbar sind, nicht auch für andere Benutzer des Systems lesbar sein können? ;)