apache mit mod_userdir + php5 sicherheit

[marcel-182]

hallo,

erstmal die ausgangssituation:
- root-server mit debian sarge
- apache 2.2.0 (läuft als wwwuser/wwwgroup)
- php 5.1.2
- für die einzelnen benutzer wurde ein user + home-verzeichnis angelegt
- websites etc. können in /home/*/public_html via ftp hochgeladen werden
- der ftpd benutzt jeweils den angelegten user des benutzers (pureftpd)

das ganze läuft auch ohne probleme und die anderen benutzer sind vertrauenswürdig, allerdings ist mir nicht so ganz wohl bei der ganzen sachen. die benutzer sollen die php scripte nur mit ihrem eigenen user ausführen können bzw. würde es mir schon reichen wenn sie nur dateien innerhalb ihres eigenen home-verzeichnisses lesen/schreiben könnten. bekannt sind mir bisher 2 mögichkeiten: suphp und fcgi+suexec.

suphp ist leider zu langsam und kommt sowieso nicht in frage, weil es nicht mit apache > 2.0.* läuft. fcgi+suexec wäre natürlich die beste lösung. allerdings ist es etwas schwierig zu konfigurieren und funktioniert meines wissens nur im zusammenhang mit vhosts.


meine frage:
gibt es noch andere möglichkeit? wäre es möglich die rechte irgendwo so zu setzen, dass der apache-user nicht aus dem home-verzeichnis des jeweiligen benutzers "ausbrechen" kann?


danke im vorraus

[Roger Wilco]

suphp ist leider zu langsam und kommt sowieso nicht in frage, weil es nicht mit apache > 2.0.* läuft.

mod_fastcgi und mod_fcgid laufen auch nicht mit Apache 2.2.

gibt es noch andere möglichkeit?

Für jeden Benutzer eine gechrootete Instanz des Apache (oder vielleicht einen anderen httpd) laufen lassen. Frag mal flo. ;)

[flo]

Ich habe mich gegen den richtigen chroot entschieden:

- weil ich keine wesentlichen Vorteile mehr sehe
- meine Leute sowenig wie möglich selber löschen können sollen - die Libs und Binaries in den Homes, wo sie ja dann eigentlich hingehören, würden meine Leute nur verwirren
- der zusätzliche Speicherplatz mir zu schade wäre - dreißigmal kompletten Lamp auf der Platte fände ich übertrieben

Die Installation über den Proxy bietet viel Komfort mit relativ guter Sicherheit auf Kosten eines immens hohen Ressourcenverbrauchs - ohne Athlon64/3000/1GB mit extra Mail- und Datenbankservern ist das illusorisch, und ich habe nur 30 Angebote auf dem Rechner.

Naja, beim RSAC-Treffen muß ich JoeUser mal entfürhen und ihn zum lighthttpd interviewen. ;-)

flo.

[marcel-182]

hallo nochmal,

mod_fcgid unterstützt in der neuesten version jetzt auch apache 2.2.0. hab das ganze vorhin mal auf einem testsystem ausprobiert. bin allerdings an der konfiguration für UserDir gescheitert ;). wenn ich ein php-script in einem der public_html aufruf kommt immer ein internal server error.

weiss jetzt echt nicht mehr weiter und hoffe mal, dass mir jemand erklären kann was ich falsch gemacht hab.


hier meine konfiguration und der fehler:

suexec_log steht:

Code: Select all

[2006-04-29 00:09:02]: command not in docroot (/opt/bin/php-5.1.2/bin/php-fcgi)

meine httpd-userdir.conf sieht so aus:

Code: Select all

UserDir public_html

<Directory /home/*/public_html>
    FCGIWrapper /opt/bin/php-5.1.2/bin/php-fcgi .php
    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch ExecCGI
    <Limit GET POST OPTIONS>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

suexec:

Code: Select all

./suexec -V
 -D AP_DOC_ROOT="/opt/bin/httpd-2.2.0/htdocs"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="httpd"
 -D AP_LOG_EXEC="/opt/bin/httpd-2.2.0/logs/suexec_log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=100
 -D AP_USERDIR_SUFFIX="public_html"

[duergner]

suexec_log steht:

Code: Select all

[2006-04-29 00:09:02]: command not in docroot (/opt/bin/php-5.1.2/bin/php-fcgi)

Hmm was will uns diese Fehlermeldung wohl sagen? Und jetzt sag bitte nicht, dass du dazu nichts gefunden hast.

[marcel-182]

die fehlermeldung sagt mir, dass mein script sich nicht im docroot befindet. allerdings befinde ich mich ja im userdir und er weiss auch wo sich dieses befindet:

Code: Select all

-D AP_USERDIR_SUFFIX="public_html"

im der dokumentation steht:

Code: Select all

Is the directory within the Apache webspace?

If the request is for a regular portion of the server, is the requested directory within suEXEC's document root? If the request is for a UserDir, is the requested directory within the directory configured as suEXEC's userdir (see suEXEC's configuration options)?

und jetzt verrat mir bitte des rätsels lösung :)

[duergner]

Vergleiche doch mal was du als UserDir hast und wo dein PHP Binary liegt.

[marcel-182]

hm... ich hab das php binary jetzt mal in den public_html ordner von einem user verschoben und die httpd-userdir.conf angepasst. es funktioniert jetzt auch für den einen benutzer und wird auch mit dem richtigen user ausgeführt. aber was ist mit den anderen usern? reicht es nicht wenn man 1 binary irgendwo installiert hat und dieses benutzt oder muss man jedem user ein binary ins userdir schieben? und wie muss die config dann aussehen? fragen über fragen.

/me versteht nur noch bahnhof :S


aktuelle httpd-userdir.conf:

Code: Select all

UserDir public_html

<Directory /home/*/public_html>
    FCGIWrapper /home/marcel/public_html/php-5.1.2/bin/php-fcgi .php
    #FCGIWrapper /opt/bin/php-5.1.2/bin/php-fcgi .php
    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch ExecCGI
    <Limit GET POST OPTIONS>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

[duergner]

Meines Wissens nach geht das nicht anders als das PHP Binary in jedes UserDir zu schieben. Aber bemühe mal die Forensuche etwas. Wenn mich nicht alles täuscht, gab's da vor kurzem mal einen Thread dazu.

[marcel-182]

hab die forensuche schon benutzt aber nichts gefunden was mir bei meinem problem weiterhilft...

[andreask2]

Also ich würde mir glaube ich auch mal lighttpd ansehen, damit lässt sich sowas wirklich einfach umsetzen:

http://trac.lighttpd.net/trac/wiki/HowT ... ermissions
http://trac.lighttpd.net/trac/wiki/SuEXEC

Ist denke ich auch die effizientere Variante.

[marcel-182]

das mit lighttpd wäre durchaus eine überlegung wert.. auf der website steht auch, dass es mod_userdir gibt. da bin ich aber wieder beim alten problem: nirgendwo steht wie man das ganze im zusammenhang mit userdirs konfiguriert, sondern nur wie man es mit vhosts macht -> http://trac.lighttpd.net/trac/wiki/HowT ... ermissions

[andreask2]

Setze doch einfach einen Proxy davor, der entsprechend auf interne vhosts weiterleitet.

[marcel-182]

lighttpd scheint ja echt klasse zu sein. aber ich weiss einfach nicht, wie ich das mit den vhosts machen soll. deswegen bin ich auch so versessen darauf, mod_userdir zu benutzen. ich hab nur eine ip-adresse und KEINE domain. gibt es denn eine möglichkeit die vhosts so zu konfigurieren, dass die user zugriff auf ihr verzeichniss via http://ip/user1, http://ip/user2 etc. haben? als document root kann ich dann ja für jeden vhost das public_html verzeichnis des users einstellen.

[andreask2]

Ich weiß nicht ob das mit mod_userdir geht, vermutlich aber eher nicht, weil die Lösungen meines Wissens alle auf individuellen vhosts aufbauen. Wenn das also nicht anders geht, könntest Du einen proxy installieren, z.B. Apache mod_proxy, damit kannst Du, zusammen mit mod_rewrite eine RewriteRule erstellen, die

http://ip/[user1] auf http://[user1].interne-domain.local umleitet.

*.interne-domain.local kannst Du dann auf eine andere, lokale IP und/oder einen anderen Port schicken, und da dann entweder mit Apache oder besser lighttpd ganz normal mit vhosts arbeiten.

[marcel-182]

hallo,

ich glaube eine bessere lösung (mit lighttpd) gefunden zu haben.


anstatt mit vhosts wie hier beschrieben:
http://trac.lighttpd.net/trac/wiki/HowT ... ermissions

will ich es so machen:
http://blog.lighttpd.net/articles/2005/ ... rails-apps

ich hoffe, dass klappt auch so wie ich es mir gedacht hab :D.

[andreask2]

wusste gar nicht dass das geht! Cool! Dann würde ich einfach die beiden ansätze kombinieren!