Verständnisfragen zum debianhowto.de:apache2_php-fcgi

[floogy]

Hallo,

Ich hoffe Ihr könnt ein wenig Licht in die Sache bringen.
Um eine flexiblere und vor allem sichere Webserverkonfiguration zu bekommen würde ich gerne das HOWTO, oder ähnliche Ansätze umsetzen.

Erst mal, was ist mit der Weiterentwicklung des HOWTOS? Die etch version wirkt arg beschnitten:
http://debianhowto.de/doku.php/de:howto ... 2_php-fcgi
Die sarge-version scheint aktueller zu sein (letzte Änderungen):
http://debianhowto.de/doku.php/de:howto ... 2_php-fcgi

Ich habe versucht das ganze mal exemplarisch auf meinem ubuntu/gutsy/amd64 Desktop nachzuvollziehen.

Dabei gibt es ein paar Verständnisprobleme, und ein Problem mit meiner Entwicklungsumgebung, die ich auch für Windows bereithalten möchte (xampp).

Der Hintergrund ist aber mehr der Lerneffekt, und das Vorhaben meinen debian/etch vserver von apache 1.3.x auf apache2.2-mpm-worker umzustellen, und zwar von mod_php auf php5_fcgi.

Zu den Fragen:

1.
Ich konnte kein php5_fcgi oder php_fcgi unter gutsy finden. Ist php5-cgi das richtige binary?

Code: Select all

zless /usr/share/doc/php5-cgi/README.Debian.gz

Our recommendation is that, if you need
to use a threaded webserver, you should use php5-cgi in either
'normal' CGI mode, or in FastCGI mode.

Verstehe ich so, dass php5-cgi das entsprechend zu nutzende binary ist, es ist im Paket php5-cgi enthalten.

phpinfo() spuckt u.a. folgende Zeile aus:

Code: Select all

Server API 	CGI/FastCGI

Ich nehme mal an, dass damit bestätigt ist, dass das php5-cgi binary vom fastCGI-server korrekt ausgeführt wird.
pstree gibt das hier aus:

Code: Select all

     ├─apache2─┬─apache2
     │         ├─apache2───php5-cgi───4*[php5-cgi]
     │         └─2*[apache2───26*[{apache2}]]

2.
Was bedeuten die Variablen in der fastcgi.conf? PRIM_VHOST/php-fcgi-starter -user USER_PRIM_VHOST -group TGROUP_PRIM_VHOST
Ist die Konfiguration richtig?

Der apache startet folgendermaßen:

Code: Select all

[Tue Oct 23 19:51:17 2007] [notice] caught SIGWINCH, shutting down gracefully
[Tue Oct 23 19:51:27 2007] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Tue Oct 23 19:51:27 2007] [notice] Digest: generating secret for digest authentication ...
[Tue Oct 23 19:51:27 2007] [notice] Digest: done
[Tue Oct 23 19:51:28 2007] [notice] FastCGI: wrapper mechanism enabled (wrapper: /usr/lib/apache2/suexec2)
[Tue Oct 23 19:51:28 2007] [notice] FastCGI: process manager initialized (pid 9179)
[Tue Oct 23 19:51:28 2007] [warn] FastCGI: server "/var/www/php-fcgi-scripts/mypages.home/php-fcgi-starter" (uid 1000, gid 151) started (pid 9180)
[Tue Oct 23 19:51:28 2007] [notice] Apache/2.2.4 (Ubuntu) mod_fastcgi/2.4.2 mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations

Ich nehme mal an, dass es sinnvoller wäre die Gruppe auf eine ID höher 2000 zu setzen.

Der Dateibaum sieht folgendermaßen aus:

Code: Select all

var
`--www
   |--php-fcgi-scripts
   |   |-- index.html
   |   |-- mypages.home
   |   |   |-- index.html
   |   |   `-- php-fcgi-starter
   |   `-- www.vhost1.home
   |       |-- index.html
   |       `-- php-fcgi-starter
   |--mypages.home
   |   |-- conf
   |   `-- web
   |       `-- index.php
   `--www.vhost1.home
      |-- conf
      `-- web
           `-- index.php

Unter /etc/apache2/sites-available habe ich folgenden vhost unter dem Dateinamen http://www.vhost1.home eingetragen, und nach sites-enabled verlinkt:

Code: Select all

<VirtualHost 172.16.240.1:80>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/www.vhost1.home/web

        #http://archiv.debianhowto.de/de/apache2-phpfcgi-sarge/c_apache2-phpfcgi-sarge.html
        ServerName www.vhost1.home
        ServerAlias www.vhost1.home

        DirectoryIndex index.php index.html index.htm
        SuexecUserGroup floogy www-fcgi

        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/www.vhost1.home/web>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
                # This directive allows us to have apache2's default start page
                # in /apache2-default/, but still have / go to the right place
                #RedirectMatch ^/$ /apache2-default/
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ 
                <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews -Indexes +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/www.vhost1.home-error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/www.vhost1.home-access.log combined
        ServerSignature On

</VirtualHost>

/etc/apache2/mods-available/fastcgi.conf:

Code: Select all

#http://archiv.debianhowto.de/de/apache2-phpfcgi-sarge/c_apache2-phpfcgi-sarge.html
<IfModule mod_fastcgi.c>
  AddHandler fastcgi-script .fcgi .php
  FastCgiWrapper /usr/lib/apache2/suexec2
  FastCgiIpcDir /var/lib/apache2/fastcgi
  FastCgiServer /var/www/php-fcgi-scripts/mypages.home/php-fcgi-starter -user floogy -group www-fcgi
<Location /cgi-bin/php-fcgi-starter>
        SetHandler fastcgi-script
        Options +ExecCGI
</Location>

Action php-fastcgi /cgi-bin/php-fcgi-starter

AddType application/x-httpd-php .php

Die Frage ist, ob -user floogy -group www-fcgi, <Location>, Action
und ob der ScriptAlias ok ist (der ScriptAlias war Distributionsmäßig so eingetragen, und ich habe ihn so belassen, im HOWTO ist er anders):

Code: Select all

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ 
                <Directory "/usr/lib/cgi-bin">

FastCgiServer /var/www/php-fcgi-scripts/PRIM_VHOST/php-fcgi-starter -user USER_PRIM_VHOST -group TGROUP_PRIM_VHOST

Ich kapier nicht ganz, ob es sich um Variablen handelt, die ich bei der Bearbeitung der Konfiguration ersetze, oder ob das Variable sind, die irgendwie vom apache2 eingesetzt werden. Und was heißt in diesem Zusammenhang PRIM=primär?

Die vhost-datei mypages.home sieht analog aus.

3.
Nun ist das eigentliche Verzeichnis von http://www.vhost1.home auf einer ntfs-3g Partition. Ich habe versucht mit symlinks zu arbeiten, was mit den *.php Dateien nicht funktioniert:

Code: Select all

[Tue Oct 23 20:10:50 2007] [error] [client 172.16.240.1] SoftException in Application.cpp:199: Script "/var/www/www.vhost1.home/web/kontakt.php" resolving to "/mnt/export/www.vhost1.home/kontakt.php" not within configured docroot, referer: http://www.vhost1.home/index.php

Die index.php habe ich kopiert, das funktionierte ebenfalls erstmal nicht:

Code: Select all

[Tue Oct 23 20:03:36 2007] [error] [client 172.16.240.1] SoftException in Application.cpp:231: File "/var/www/www.vhost1.home/web/index.php" is writeable by group
[Tue Oct 23 20:03:36 2007] [error] [client 172.16.240.1] Premature end of script headers: index.php

Nach einer Anpassung der Rechte funktionierte es aber, auch wurden alle symlinks aufgelöst, nur die php-Dateien sind nicht über symlinks zu realisieren.

Dazu das HOWTO:

Installation eines eigenen suexec Binarys

Warnung

Dieses Kapitel sollte nur dann bearbeitet werden, wenn man ein Datei-System hat, das kein immutable-Bit setzen kann oder wenn man ein anderes DocumentRoot als /var/www hat. 99% aller Leser können dieses sehr aufwendige Kapitel also getrost überspringen

Edit: Ein Symlink /var/www auf ein ggf. anderes DocumentRoot hilft auch, ohne dass man das suexec neu bauen muss.

Das scheint aber nicht zu funktionieren. Was ist hier falsch?

4.
Ist es mit diesem HOWTO leicht möglich php5-cgi mittels fcgi und suexec mit unterschiedlichen Nutzern und Gruppen laufen zu lassen, so dass ein Einbruch wirklich auf den vhost und sein Verzeichnis beschränkt bleibt?
In diesem Zusammenhang ist das lighthttpd HOWTO ganz interessant: http://www.rootforum.org/forum/viewtopic.php?t=47409
Ist das leicht auf den apache übertragbar?


5.
Sind inzwischen andere Konfigurationen sinnvoller, ist das HOwTO noch "state of the art"?

6.
Ich nutze den opcode-Cache APC. Wird das mit fastCGI und suexec funktionieren, mit suphp ja wohl nicht?

Vielen Dank im Voraus.


EDIT: Ich würde mich auf eine Antwort für die ein oder andere Frage freuen!
Glücklicherweise bin ich nun über diesen thread gestolpert:
http://www.debianforum.de/forum/viewtopic.php?t=78073
Wichtige Hinweise scheint es auch hier zu geben:
http://blog.zugschlus.de/archives/286-fastcgi.html

Ich arbeite das gerade durch.

[Roger Wilco]

1.
Ich konnte kein php5_fcgi oder php_fcgi unter gutsy finden. Ist php5-cgi das richtige binary?

Schau dir doch einfach mal die Ausgabe von `php5-cgi -v` an. ;)

Verstehe ich so, dass php5-cgi das entsprechend zu nutzende binary ist, es ist im Paket php5-cgi enthalten.

Ja.

2.
Was bedeuten die Variablen in der fastcgi.conf? PRIM_VHOST/php-fcgi-starter -user USER_PRIM_VHOST -group TGROUP_PRIM_VHOST
Ist die Konfiguration richtig?

PRIM_VHOST -> Pfad zu deinem DocumentRoot des VirtualHosts bzw. der Pfad zu dem Starterskript für PHP.
USER/GROUP_PRIM_VHOST -> Benutzername/Gruppe, unter dem die Skripte laufen sollen.

Die Frage ist, ob -user floogy -group www-fcgi, <Location>, Action
und ob der ScriptAlias ok ist (der ScriptAlias war Distributionsmäßig so eingetragen, und ich habe ihn so belassen, im HOWTO ist er anders):

Wenn das der Benutzer/die Gruppe ist, unter dem alles laufen soll, sind die Einstellungen ok. Das ScriptAlias kannst du im Prinzip erstmal vergessen.

Ich kapier nicht ganz, ob es sich um Variablen handelt, die ich bei der Bearbeitung der Konfiguration ersetze, oder ob das Variable sind, die irgendwie vom apache2 eingesetzt werden. Und was heißt in diesem Zusammenhang PRIM=primär?

PRIM_VHOST, USER/GROUP_PRIM_VHOST sind Werte, die du selbst in die Apache-Konfiguration konkret für dein Setup eintragen musst.

3.
Nun ist das eigentliche Verzeichnis von http://www.vhost1.home auf einer ntfs-3g Partition. Ich habe versucht mit symlinks zu arbeiten, was mit den *.php Dateien nicht funktioniert

Symlinks und SuExec sind ein No-Go. Und das ist auch gut so[tm]. Alternative wäre `mount --bind /mnt/export/[...]/ /var/www/[...]`.

4.
Ist es mit diesem HOWTO leicht möglich php5-cgi mittels fcgi und suexec mit unterschiedlichen Nutzern und Gruppen laufen zu lassen, so dass ein Einbruch wirklich auf den vhost und sein Verzeichnis beschränkt bleibt?

Definiere "leicht". Die Skripte werden einfach unter einer spezifischen Benutzerkennung ausgeführt. Wenn das System schlampig eingerichtet wurde, kann damit trotzdem noch Schaden angerichtet werden.

In diesem Zusammenhang ist das lighthttpd HOWTO ganz interessant: http://www.rootforum.org/forum/viewtopic.php?t=47409
Ist das leicht auf den apache übertragbar?

Der Effekt ist der gleiche. Wieso willst du das übertragen?

5.
Sind inzwischen andere Konfigurationen sinnvoller, ist das HOwTO noch "state of the art"?

mod_fastcgi für den Apache httpd ist, wie du vllt. schon selbst herausgefunden hast, veraltet. mod_fcgid hingegen unterstützt nicht alle Features von mod_fastcgi. Das Howto ist also mehr oder weniger veraltet.

6.
Ich nutze den opcode-Cache APC. Wird das mit fastCGI und suexec funktionieren, mit suphp ja wohl nicht?

Ja, Opcode-/Bytecode-Caches funktionieren mit FastCGI.

[daemotron]

3.
Nun ist das eigentliche Verzeichnis von http://www.vhost1.home auf einer ntfs-3g Partition. Ich habe versucht mit symlinks zu arbeiten, was mit den *.php Dateien nicht funktioniert

Symlinks und SuExec sind ein No-Go. Und das ist auch gut so[tm]. Alternative wäre `mount --bind /mnt/export/[...]/ /var/www/[...]`.

Dazu kommt, dass ntfs-3g AFAIR immer 777 für Verzeichnisse bzw. 666 für Dateien simuliert, da NTFS nativ ja keine Unix-Berechtigungen beherrscht. Dass suexec das überhaupt nicht mag, dürfte wohl klar sein...

[floogy]

3.
Nun ist das eigentliche Verzeichnis von http://www.vhost1.home auf einer ntfs-3g Partition. Ich habe versucht mit symlinks zu arbeiten, was mit den *.php Dateien nicht funktioniert

Symlinks und SuExec sind ein No-Go. Und das ist auch gut so[tm]. Alternative wäre `mount --bind /mnt/export/[...]/ /var/www/[...]`.

Danke Roger,

da ich gerade für eine halbe Stunde wenig Zeit habe, erst mal schon dieser Punkt: Ich habe befürchtet das das nicht geht, Ich werde mir wohl überlegen auf ext3 umzustellen, und windows-treiber für den Zugriff unter windows verwenden (extra Partition), für den öffentlichen vserver kommt das sopwieso nicht in Frage. Danke auch für den Tipp mit mount --bind, werde das in Betracht ziehen, aber wegen der fehlenden Rechteverwaltung der Windows-FS wird das wohl auch keine Option sein.

Aber wie kommt das hier zustande:
http://www.debianforum.de/forum/viewtop ... 803#570803

ich habe mit symlinks, die nach außerhalb von /var/www zeigen, keine probleme...
suexec -V gibt die gleiche Ausgabe wie bei dir
in der vhost konfig ist documentroot dann z.b. /var/www/symlink/html

[Joe User]

aber wegen der fehlenden Rechteverwaltung der Windows-FS

NTFS arbeitet mit ACLs und kennt somit user und group sowie diverse Zugriffsrechte und zudem auch (Soft)Links, lediglich die Implementierung ist anders als bei *NIX.

[floogy]

Ja, sorry für die Ungenauigkeit, es sorgt aber im Falle ntfs-3g für Inkompatibilitäten mit suexec, wenn ich das richtig verstehe.

[floogy]

Hallo Roger,
vielen Dank, dass Du, sowie jfreund und Joe User, euch die Mühe gemacht habt das ganze durchzulesen.

1.
Ich konnte kein php5_fcgi oder php_fcgi unter gutsy finden. Ist php5-cgi das richtige binary?

Schau dir doch einfach mal die Ausgabe von `php5-cgi -v` an. ;)

Danke, das hatte ich dann auch inzwischen entdeckt.

2.
Was bedeuten die Variablen in der fastcgi.conf? PRIM_VHOST/php-fcgi-starter -user USER_PRIM_VHOST -group TGROUP_PRIM_VHOST
Ist die Konfiguration richtig?

PRIM_VHOST -> Pfad zu deinem DocumentRoot des VirtualHosts bzw. der Pfad zu dem Starterskript für PHP.
USER/GROUP_PRIM_VHOST -> Benutzername/Gruppe, unter dem die Skripte laufen sollen.

Hmmm... Die fastcgi.conf enthält ja nur die Angaben für einen VHOST, wenn ich das so umsetze, so kann ein php-skript das mit einem exploit ausgenutzt wird ja in alle anderen VHOST schreiben? Wo legt man sonst fest, mit welchem benutzer/gruppe fastcgi das php-binary ausführt?

Das ScriptAlias kannst du im Prinzip erstmal vergessen.

Das ScriptAlias benötige ich nur für site-available/default ?? oder site-available/mypages.home (in meinem Fall)??

PRIM_VHOST, USER/GROUP_PRIM_VHOST sind Werte, die du selbst in die Apache-Konfiguration konkret für dein Setup eintragen musst.

Das legt dann aber für alle VHOST den gleichen Benutzer/Gruppe fest?

4.
Ist es mit diesem HOWTO leicht möglich php5-cgi mittels fcgi und suexec mit unterschiedlichen Nutzern und Gruppen laufen zu lassen, so dass ein Einbruch wirklich auf den vhost und sein Verzeichnis beschränkt bleibt?

Definiere "leicht". Die Skripte werden einfach unter einer spezifischen Benutzerkennung ausgeführt. Wenn das System schlampig eingerichtet wurde, kann damit trotzdem noch Schaden angerichtet werden.

Nun, wie man zuvor sehen kann kapier ich hier zentral nicht, wie die benutzer/gruppen Berechtigung per fastcgi/suexec dem php-binary mitgegeben werden. Wo wird das konfiguriert? Im php-fcgi-starter-script ist ja nur der Pfad zur php-config angegeben, oder wird das in der php.ini geregelt?
EDIT: Wird das etwa im vHost sites-available/VHOST jeweils durch die Zeile

Code: Select all

SuexecUserGroup www-fcgi www-fcgi 

festgelegt, die dann von der Vorgabe in der fastcgi.conf abweichen kann? Etwa so:

Code: Select all

SuexecUserGroup www-vhost1 www-fcgi

oder:

Code: Select all

SuexecUserGroup www-vhost2 www-fcgi

??? <--- Das könnte eventuell die Erklärung meiner Begriffstutzigkeit sein?!

In diesem Zusammenhang ist das lighthttpd HOWTO ganz interessant: http://www.rootforum.org/forum/viewtopic.php?t=47409
Ist das leicht auf den apache übertragbar?

Der Effekt ist der gleiche. Wieso willst du das übertragen?

Wegen oben geschilderter Unklarheiten?

5.
Sind inzwischen andere Konfigurationen sinnvoller, ist das HOwTO noch "state of the art"?

mod_fastcgi für den Apache httpd ist, wie du vllt. schon selbst herausgefunden hast, veraltet. mod_fcgid hingegen unterstützt nicht alle Features von mod_fastcgi. Das Howto ist also mehr oder weniger veraltet.

Ja, das habe ich auch herausgelesen, allerdings, wo liegen die Stärken und Schwächen der beiden Methoden? Was geht mit fcgid nicht?

Ja, Opcode-/Bytecode-Caches funktionieren mit FastCGI.

Schön.

Nochmals Danke für die Mühe!

[floogy]

Nun, wie man zuvor sehen kann kapier ich hier zentral nicht, wie die benutzer/gruppen Berechtigung per fastcgi/suexec dem php-binary mitgegeben werden. Wo wird das konfiguriert? Im php-fcgi-starter-script ist ja nur der Pfad zur php-config angegeben, oder wird das in der php.ini geregelt?
EDIT: Wird das etwa im vHost sites-available/VHOST jeweils durch die Zeile

Code: Select all

SuexecUserGroup www-fcgi www-fcgi 

festgelegt, die dann von der Vorgabe in der fastcgi.conf abweichen kann? Etwa so:

Code: Select all

SuexecUserGroup www-vhost1 www-fcgi

oder:

Code: Select all

SuexecUserGroup www-vhost2 www-fcgi

??? <--- Das könnte eventuell die Erklärung meiner Begriffstutzigkeit sein?!

Ich habe nun nochmal in das fighthttpd fastcgi howto hineingeschaut, und denke inzwischen, dass die fastcgi Prozesse ihren user von der user:group Berechtigung des php-fastcgi-starter skripts erben.

Aus dem Apache 2 mit PHP 4/5 als FastCGI debianHOWTO:

Warnung

Bei dem PHP-FCGI-STARTER-Dir bzw den darin befindlichen Files sind die richtigen Rechte ganz besondern wichtig, da ansonsten eine große Sicherheitslücke entsteht. Der User könnte dieses Script dann bearbeiten und so eine beliebige php.ini bzw sogar ein beliebiges PHP-Binary hochladen.

# cd /var/www
# mkdir php-fcgi-scripts
# chown root:root php-fcgi-scripts
# cd php-fcgi-scripts
# mkdir VHOST
# chown VHOST_USER:VHOST_GROUP VHOST
# cd VHOST
# touch php-fcgi-starter
# chown VHOST_USER:VHOST_GROUP php-fcgi-starter
# chmod 755 php-fcgi-starter

Naja: Typischer Fall von Brett vorm Kopp...

Das ist also der Unterschied, den ich nicht gesehen habe:

Code: Select all

VHOST_USER:VHOST_GROUP VHOST

php-fcgi-starter

Code: Select all

FastCgiServer /var/www/php-fcgi-scripts/PRIM_VHOST/php-fcgi-starter -user USER_PRIM_VHOST -group GROUP_PRIM_VHOST

fastcgi.conf

USER_PRIM_VHOST != VHOST_USER
GROUP_PRIM_VHOST != VHOST_GROUP VHOST

Im lighthttpd HOWTO wird das im Vergleich der drei exemplarischen user/vhosts eher klar. Eine explizite Definition der Variablen in erklärenden Worten wäre eventuell zu begrüßen.

Gehen meine Überlegungen inzwischen hoffentlich in etwa in die richtige Richtung?

[Roger Wilco]

Im lighthttpd HOWTO wird das im Vergleich der drei exemplarischen user/vhosts eher klar. Eine explizite Definition der Variablen in erklärenden Worten wäre eventuell zu begrüßen.

Das Howto steht in einem Wiki. Es wäre eventuell zu begrüßen, wenn du unklare Passagen durch erklärende Worte ergänzt, damit sich der nächste Benutzer freut.

[floogy]

Ich habe hier irgendwo 1) gelesen, dass speziell das debianhowto.de zwar technisch ein wiki darstellt, die einzelnen Artikel allerdings stark am Author gebunden sind.

Beim Durchlesen der aktuellen Lizenz kann ich das aber nicht finden. Was sagt denn kase[at]debianhowto.de dazu?

Zuerst muß ich aber mal verstehen, worum es überhaupt geht

1) EDIT: Habs gefunden:
http://blog.zugschlus.de/archives/286-fastcgi.html#c648
Dem steht natürlich die Lizenz entgegen, die Timo dem HOWTO gegeben hat.

[Roger Wilco]

Beim Durchlesen der aktuellen Lizenz kann ich das aber nicht finden. Was sagt denn kase[at]debianhowto.de dazu?

http://debianhowto.de/doku.php/de:howto ... und_lizenz

[floogy]

Beim Durchlesen der aktuellen Lizenz kann ich das aber nicht finden. Was sagt denn kase[at]debianhowto.de dazu?

http://debianhowto.de/doku.php/de:howto ... und_lizenz

Ich hätte schreiben sollen:

Beim Durchlesen der aktuellen Lizenz kann ich das aber nicht bestätigt finden.

Was denkst Du zu meinem letzten Post zur Sache:

dass die fastcgi Prozesse ihren user von der user:group Berechtigung des php-fastcgi-starter skripts erben.

Mir ist das nicht aufgefallen, da ich allen vhosts www-fcgi:www-fcgi verpasste. Sinnvoller wäre da wohl www-vhost-1:www-fcgi, www-vhost2:www-fcgi, und der Gruppe, zur Abschottung untereinander, weniger Rechte einräumen. Bin mir da immer noch nicht sicher.

[duergner]

Mir ist das nicht aufgefallen, da ich allen vhosts www-fcgi:www-fcgi verpasste. Sinnvoller wäre da wohl www-vhost-1:www-fcgi, www-vhost2:www-fcgi, und der Gruppe, zur Abschottung untereinander, weniger Rechte einräumen. Bin mir da immer noch nicht sicher.

Ja sinnvoller waere das, da dann naemlich auch die PHP Scripten die mittels HTTP POST/PUT uebertragenen Dateien lesen koennten, allerdings ist das einzige MPM des Apache2, soweit ich weiss, welches das unterstuetzen wuerde das perchild. Und wenn mich nicht alles taeucht, dann ist die Entwicklung an diesem MPM mehr oder weniger tot.

worker und perfork unterstuetzen meines Wissens nach keine unterschiedlichen Benutzer pro VHost, da die VHost Prozesse nur von Hauptprozess aus geforkt werden.

Das fuehrt natuerlich auch dazu, dass nahezu keine Webapp, die mit Uploads arbeitet in einem hinreichend sicher konfigurierten System sinnvoll einsetzbar ist. Der einzige Workaround den ich dazu kenne ist, einen Cronjob laufen zu lassen, der in moeglichst kurzen Zeitabstaenden die Owner/Group korrekt setzt.

[floogy]

Ich dachte, das HOWTO sei gerade dazu geschrieben worden, um diese Probleme in den Griff zu bekommen?
Bleibt da nur noch die höhere Performance, und der flexiblere Umgang mit der php-Konfiguration? Der Zugewinn an Sicherheit beschränkt sich wiederum nur auf die user:gruppe unter dem sämtliche fastcgi Prozesse gleichermaßen laufen müssen? Wo ist da der Vorteil, ob www-data das Sicherheitsloch reißt, oder www-fcgi (in meinem Beispiel)?

Ich nehme mal an mit Lighty verhält es sich dann auch nicht anders?

Jetzt bin ich doch etwas verwirrt. Leider habe ich noch immer nicht die nötige Zeit gefunden die beiden entsprechenden Mega-Threads hier und in debianforum.de genauestens zu lesen, was mir zugegebenermaßen wegen der relativ großen Unübersichtlichkeit etwas schwer fällt.

EDIT: Die beiden Artikel in diesem thread sprechen aber eine andere Sprache. Demnach ist es auch mit suexec/fastcgi möglich die php-prozesse unter individuellen UID/GID laufen zu lassen:
Unterschied / Vorteil spawn_cgi und fast_cgi
http://www.rootforum.org/forum/viewtopi ... 054#290054
Oder ist das tatsächlich, wie duergner andeutete mit dem apachen nicht möglich?
Werde mich mal weiter in die Tiefe der threads versenken...

[sonnenrot]

Hi ich bin derjenige der das HowTo, welches du gelesen hast ins deutsche übersetzt hat.

Das Ziel des Tutorials ist es mehrere Benutzer oder auch Projekte (wie in meinem Fall) voneinander zu trennen.

Die jeweiligen Benutzer spawnen dann ebenfalls mehrere PHP Prozesse (kannst du selbst angeben), welche die Seite erstellen.
Hierbei ist darauf zu achten das der PHP Prozess mit den selben Rechten des Ordner besitzer läuft, wodurch auch nur dessen Rechte für ihn gelten.

Durch Möglichkeiten wie open_bsdir kann man sich relativ vor korumpierbaren Code schützen.

Der Lighty übernimmt hierbei die Aufgabe die mittels PHP generierten Inhalte auszuliefern.

Wo ist da der Vorteil, ob www-data das Sicherheitsloch reißt, oder www-fcgi (in meinem Beispiel)?

www-fcgi liefert
www-user1 darf verändern - das hat zur Folge das bei richtig gesetzten Rechten ein User mit den Rechten des Apache deine Seiten nicht verändern kann.

[floogy]

Hallo sonnenrot,

Das Ziel des Tutorials ist es mehrere Benutzer oder auch Projekte (wie in meinem Fall) voneinander zu trennen.

Genau so hatte ich es auch verstanden, allerdings verstehe ich diese Aussage von duergner nicht ganz:

worker und perfork unterstuetzen meines Wissens nach keine unterschiedlichen Benutzer pro VHost, da die VHost Prozesse nur von Hauptprozess aus geforkt werden.

Das fuehrt natuerlich auch dazu, dass nahezu keine Webapp, die mit Uploads arbeitet in einem hinreichend sicher konfigurierten System sinnvoll einsetzbar ist. Der einzige Workaround den ich dazu kenne ist, einen Cronjob laufen zu lassen, der in moeglichst kurzen Zeitabstaenden die Owner/Group korrekt setzt.

Soweit ich das sehe kann durch suexec php oder anderen cgi code unter einer anderen UID/GID als der des apache ausgeführt werden. suexec bedeutet ja wohl soviel wie switch user before execution.

fastcgi/fcgid sorgen für die schnelle Ausführung und Speicherverwaltung des cgi-codes.

Im 3. und 4. Absatz seines suexec-Artikels geht Marc 'Zugschlus' Haber auf mpm-perchild ein und erklärt grob, wie suexec als wrapper dem CGI-code nach Überprüfung des codes auf die "innerhalb der Definition des virtual hosts explizit mit der Direktive SuexecUserGroup einen Target-User und eine Target-Group angeben"en UID/GID reduziert.
http://blog.zugschlus.de/archives/211-s ... ache2.html

duergner, betreffen Deine Überlegungen also nur die http Methoden POST/PUT, die davon nicht erfasst werden (da http-methoden), und daher nur im apachen selbst ausgeräumt werden können?

Da mpm-perchild erst mal auf Eis zu liegen scheint, wie sieht es in diesem Punkt mit Lighty aus? Ich nehme mal an, nicht anders, da man sonst ja auch dort auf fastcgi/SPAWNFCGI verzichten könnte.

Linkliste:
http://httpd.apache.org/docs/2.2/de/mod/mpm_common.html
http://httpd.apache.org/docs/trunk/de/mod/perchild.html
http://httpd.apache.org/docs/trunk/de/p ... uexec.html
http://httpd.apache.org/docs/trunk/de/suexec.html
http://httpd.apache.org/docs/trunk/de/howto/cgi.html

[Roger Wilco]

duergner, betreffen Deine Überlegungen also nur die http Methoden POST/PUT, die davon nicht erfasst werden (da http-methoden), und daher nur im apachen selbst ausgeräumt werden können?

Ja, aber das betrifft "nur" WebDAV, wenn du das einsetzt. Wenn du Dateien über ein PHP-Skript hochlädst, das unter einer bestimmten Benutzerkennung läuft, hat die hochgeladene Datei auch diese Benutzerkennung.

[floogy]

Ich habe es nun mit a3dismod fastcgi && a2enmod fcgid zum laufen gebracht. Ich hatte vorher übersehen, dass noch suphp geladen war (also musste ich vorher noch ein a2dismod suphp machen). 8O

Des weiteren vergab ich gleiche UID/GID an die einzelnen
Projekte/Kunden/vhosts, wie z.B. vh1:vh1, vh2:vh2, ging nochmal die Berechtigungen im debian HOWTO durch (z.B. VHOST/conf root:root), und kommentierte die section ScriptAlias aus /etc/apache2/sites-available/VHOST aus, und sorgte für eine Zeile FCGIWrapper und AddHandler, sowie +ExecCGI in den Options der <Directory> Direktive.

Code: Select all

$ egrep -v '#|^ *$' /etc/apache2/sites-available/default
NameVirtualHost 172.16.240.1
<VirtualHost 172.16.240.1>
        ServerAdmin webmaster@localhost
        ServerName localhost
        DocumentRoot /var/www/default/web

        DirectoryIndex index.php index.html index.htm
        SuexecUserGroup www-fcgi www-fcgi

        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/default/web>
                FCGIWrapper  /var/www/php-fcgi-scripts/default/php-fcgi-starter .php
                AddHandler fcgid-script .php
                Options Indexes FollowSymLinks MultiViews +ExecCGI
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log
        LogLevel debug
        CustomLog /var/log/apache2/access.log combined
        ServerSignature On
</VirtualHost>

Code: Select all

$ ls -l default/*
default/conf:
total 0
default/web:
lrwxrwxrwx 1 root     root     17 2007-10-27 10:59 gallery2 -> /var/www/gallery2
-rwxr-xr-x 1 www-fcgi www-fcgi 20 2007-10-26 19:14 index.php
lrwxrwxrwx 1 root     root     14 2007-10-27 02:11 munin -> /var/www/munin
lrwxrwxrwx 1 root     root     19 2007-10-27 02:11 phpmyadmin -> /var/www/phpmyadmin
lrwxrwxrwx 1 root     root     19 2007-10-27 02:11 phpsysinfo -> /var/www/phpsysinfo

Code: Select all

$ ls -l php-fcgi-scripts/default/
total 5700
-rw-r--r-- 1 www-fcgi www-fcgi      44 2004-11-20 21:16 index.html
-rwxr-xr-x 1 www-fcgi www-fcgi 5813200 2007-10-05 03:21 php5-cgi
-rwxr-xr-x 1 www-fcgi www-fcgi     182 2007-10-26 23:34 php-fcgi-starter
$ ls -ld php-fcgi-scripts/default/
drwxr-xr-x 2 www-fcgi www-fcgi 4096 2007-10-26 23:34 php-fcgi-scripts/default/

Code: Select all

$ lsattr  php-fcgi-scripts/default/php-fcgi-starter 
----i------------- php-fcgi-scripts/default/php-fcgi-starter

php-fcgi-scripts/default/php-fcgi-starter:

Code: Select all

#!/bin/sh
PHPRC="/var/www/default/conf"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
#exec /PATH/TO/PHP-BINARY/php-fcgi
exec /var/www/php-fcgi-scripts/default/php5-cgi

Bei den anderen vhost funktioniert auch exec /usr/bin/php5-cgi. Frage: Liegt vielleicht hier der Grund, dass /usr/bin/php5-cgi root:root Benutzerrechte hat, dass worldreadeable-Dateien aus /etc mittels php angezeigt werden können? EDIT: Ich glaube eher nicht, da gerade das Testscript, das aus /etc lesen kann mit /var/www/php-fcgi-scripts/vh1/php5-cgi ausgeführt wird, das die Benutzerrechte vh1:vh1 hat.


Die Symlinks unter /var/www/ bzw. /var/www/default/web funktionieren übrigens tatsächlich.

Worldreadeable Dateien z.B. aus /etc können mit dem phpscript, das sonnenrot im HOWTO verwendet allerdings gelesen werden. :(
Frage: Ist das jetzt ein Zeichen, dass suexec nicht wie gewünscht funktioniert, oder habe ich etwas übersehen?

Code: Select all

 sudo /usr/lib/apache2/suexec2 -V
 -D AP_DOC_ROOT="/var/www"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="www-data"
 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=100
 -D AP_USERDIR_SUFFIX="public_html"

Hier der Prozessbaum:

Code: Select all

$ pstree -u|grep -A1 apache
     |-apache2-+-apache2(www-data)
     |         |-apache2(www-data)---2*[php5-cgi(www-fcgi)---4*[php5-cgi]]
     |         `-2*[apache2(www-data)---26*[{apache2}]]
     |-apt-watch(floogy)

Im apache2/error.log sieht das ganze dann z.B. beim vh1 so aus:

Code: Select all

[Sat Oct 27 10:47:29 2007] [notice] mod_fcgid: call /var/www/vh1/web/test.php with wrapper /var/www/php-fcgi-scripts/vh1/php-fcgi-starter
[Sat Oct 27 10:47:29 2007] [info] mod_fcgid: server /var/www/vh1/web/test.php(26178) started

Das zugehörige suexec.log:

Code: Select all

[2007-10-27 11:00:14]: uid: (1004/vh1) gid: (1004/1004) cmd: php-fcgi-starter

Die Testseite kann nicht von anderen VHOST (z.B. vh2) lesen (mit dem code von sonnenrot in seiner "lighthttpd individuelle Userrechte HOWTO" Übersetzung http://www.rootforum.org/forum/viewtopic.php?t=47409.), und

Code: Select all

<?php
echo "<br /><b>UID:".+posix_getuid()."<br />GID:".+posix_getgid()."</b><br /><br />";
?>

bringt

UID: 1004
GID: 1004

Mit fascgi bin ich auch nach der Deaktivierung von suPHP nicht klargekommen:
error.log:

Code: Select all

 [warn] FastCGI: (dynamic) server "/var/www/index.php" (pid 7034) terminated by calling exit with status '255'
suexec policy violation: see suexec log for more details

suexec.log:

Code: Select all

[2007-10-26 22:09:24]: uid: (www-fcgi/www-fcgi) gid: (151/151) cmd: index.php
[2007-10-26 22:09:24]: (8)Exec format error: exec failed (index.php)

Oder er wollte das php-File herunterladen, oder gab ein Server 500 Fehler aus.
http://www.debianforum.de/forum/viewtop ... 293#571293
http://www.debianforum.de/forum/viewtop ... 662#501662

Die verwendete php.ini ist unter /etc/php5/cgi, da unter VHOST/conf noch keine angelegt wurde.

Vielen Dank, allen, die sich für das Thema interessiert haben, und die mir halfen.

[Joe User]

worldreadable Files können grundsätzlich von Jedem gelesen werden, deshalb ja auch world ;)

[floogy]

Danke für die Klarstellung, Joe User.
Was denkst Du zu der Konfiguration im letzten Post? Ist alles richtig?
Wie ist das mit den Symlinks, von denen Roger Wilco meinte, dass sie ein "NoGo" für suexec seien, oder meinte er etwas anderes?

[floogy]

worldreadable Files können grundsätzlich von Jedem gelesen werden, deshalb ja auch world ;)

Sorry, wenn ich den Faden noch mal aufnehme, aber es bestehen noch einige Unklarheiten über das Maß einer sinnvollen Sicherheitseinstellung.

Ich kann z.B. mit readfile /etc/passwd lesen in dieser Konstellation, was ja, glaube ich nicht so gut ist, da es ja niemanden angeht, was für Benutzer und Gruppen sich so auf dem server tummeln, oder?

Jedenfalls hat in der debian Installation die passwd folgende Permissions:

Code: Select all

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 3041 2007-10-27 01:14 /etc/passwd

Die shadow ist dann ja auch nicht mehr world readeable.

Das ist also nach wie vor Aufgabe der php.ini oder .htaccess Einstellungen?

1. Welche Sicherheitseinstellungen sind da erforderlich, und wo gibt es dazu eine gute Einführung.
2. Wie sind die Unterschiede der php.ini verglichen mit mod_php und den cgi Varianten PHPs?
3. Gibt es automatische test tools, die meine php-Konfiguration unter Sicherheitsaspekten begutachten, und eine Art audit durchführen, und die Einstellungen bewerten und kommentieren?

Diese Tools untersuchen ja eher die PHP-Applikationen, oder?

http://www.phpdirectory.com/tools/security/

Das mit den Symlinks interessiert mich nach wie vor.

Vielen Dank im Voraus

floogy

[Roger Wilco]

Ich kann z.B. mit readfile /etc/passwd lesen in dieser Konstellation, was ja, glaube ich nicht so gut ist, da es ja niemanden angeht, was für Benutzer und Gruppen sich so auf dem server tummeln, oder?

Das hängt davon ab[tm]. Wenn ein Programm eine User ID auf einen Namen mappen will, braucht sie nunmal Lesezugriff auf die /etc/passwd. Passwörter stehen ja nicht wirklich darin.

Jedenfalls hat in der debian Installation die passwd folgende Permissions:

Code: Select all

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 3041 2007-10-27 01:14 /etc/passwd

Und das sollte auch so sein.

Welche Sicherheitseinstellungen sind da erforderlich, und wo gibt es dazu eine gute Einführung.

open_basedir restrictions. Im Zweifel auch einfach den kompletten PHP-Interpreter in eine chroot-Umgebung packen. Das geht mit spawn-fcgi recht einfach (zusammen mit nginx oder lighttpd).

Wie sind die Unterschiede der php.ini verglichen mit mod_php und den cgi Varianten PHPs?

Es gibt keine.

Gibt es automatische test tools, die meine php-Konfiguration unter Sicherheitsaspekten begutachten, und eine Art audit durchführen, und die Einstellungen bewerten und kommentieren?

phpSecInfo ist mal ein Anfang, allerdings wirklich nur ein ganz kleiner.

[floogy]

Vielen Dank für die Tipps! Wie sieht es denn allgemein mit so abgesicherten php.ini optionen aus, und der Lauffähigkeit von z.B. Typo3, Gallery2, Joomla, WordPress usw. aus? Welche Erfahrungen habt ihr da?

Code: Select all

phpSecInfo ist mal ein Anfang, allerdings wirklich nur ein ganz kleiner.

Weshalb ist das Deiner Meinung nach nur ein "ganz kleiner [...]Anfang"?