[php] wozu ist das gut

[Matthias Pigulla]

Norbert Pfeiffer wrote:
> Doch mal etwas zuerst:
> Vermengt doch nicht immer systemspezifische Dinge mit Problemen
> eines Webmasters oder anderen beliebigen 'Anwendungs-Usern'.

Ich sehe hier nicht ganz die Unterschiede.

> Der User eines Systems nutzt, was man ihm gibt, fuer seine Zwecke.
> Einer bastelt bunte Seiten, ein anderer Datenbanken oder Mathe-Tools.
> Prinzipiell ist es dem User voellig egal welches BS in Hintergrund
> wirkt, nur 'down' gehen sollte es nicht, wenn er einen Loop fabriziert.

So, und ich will als Systembetreiber meinen Rechner so konfigurieren,
daß der User eines machen kann: Webseiten servieren ;-)

Um dabei die Ausfallzeiten niedrig zu halten, muß ich sicherstellen, daß
keiner Mist bauen kann. Und um da von vorne herein Barrieren aufzubauen,
will ich z. B. nicht, daß jeder User meine Config-Files lesen kann - man
könnte ja Hinweise auf Schwachstellen finden. (Das ist nur ein Punkt,
den man in einer policy festlegen könnte.)

> Es ist ja nicht illegal, gegebene Funktionen auch zu benutzen,
> solange man nicht die Absicht hat, etwas lahm zu legen.

Nein, da sage ich ja auch nichts gegen. Ich will nur darauf hinaus, das
System so zu installieren, daß man es auch mit den gegebenen Funktionen
nicht leichter hat, Schwachstellen zu finden.

> Wieso jedoch kein Unterschied zwischen dem Apache-Vater und seinem -Kind
> einzurichten gehen soll, verstehe ich nicht ganz.

Das ist schon so... Aufgrund seines Designs läuft der Apache-Papa als
root, und die Kinder werden nach ihrer Zeugung apaches ;-)

Folglich gehören auf einem m.E. "sauberen" System die Config-Files, Logs
etc. nicht dem Apache-User, sondern einem Webadmin oder ähnlichem. Beim
Start kann der Server so immer noch darauf zugreifen.

> - Und was waere, wenn PHP als CGI-Modul laeuft, so wie Perl, da kann oder
>   sollte doch auch nicht jeder alles machen duerfen. Z.B. auf meiner
>   kleinen Linux-Kiste komme ich auch nicht ueberall hin, wenn ich das
>   Script als User oder Apache starte. Also geht es doch  <gruebel>.

Nein, nicht überall hin. Nicht in die Bereiche, in die der Apache nicht
kommt.

Wenn ich mehrere User habe, die ihre eigenen Verzeichnisse haben, die
den Usern gehören und der Gruppe des Apache, dann ist das soweit schön,
als jeder User in seinem Verzeichnis bleiben muß, aber trotzdem der
Apache überall rein kann, um die Daten zu lesen. (Vielleicht ist das ja
schon ein falsches Setup :-( ?)

Mit deinem Tool (und mit non-su CGI genauso) kannst Du halt als "Person"
des WWW-Servers Aufgaben ausführen, und damit zum Beispiel Dateien aus
den Verzeichnissen anderer User lesen, in die Du als der User, der Du
eigentlich bist, nicht reinkommen könntest.

Einleuchtendes Beispiel: Stell' Dir jetzt mal vor, einer der User hat in
seinem Verzeichnis ein PHP-Skript, in dem er mit "seiner" Datenbank
arbeitet. Zwar könntest Du auch über WWW die Seiten abrufen - die können
ja ruhig öffentlich sein -, aber Du könntest nicht den Quellcode lesen,
in dem u. a. das Kennwort für die Datenbank steht, weil ja PHP diese
Information "weginterpretiert".

Ich nehme an, das Problem leuchtet ein? 

Deshalb gibt es bei CGI sogenannter wrapper, die dafür sorgen, daß ein
Apache-Kind, bevor es CGI ausführt, nochmal ein su macht und damit zu
dem User wird, dem die ausgeführte Datei gehört. Damit hast Du dann
keine Chance mehr, als Apache-User oder mit Apache-Gruppenrechten
Aktionen auszuführen.

Sowas gibt es AFAIK bei PHP als Apache-Modul noch nicht.

Matthias
-- 
   w e b f a c t o r y | matthias pigulla
 
      am wichelshof 10   fon 0228-9636949
      53111 bonn         fax 0228- 655656
      www.webfactory.de  mp_(at)_webfactory.de