open_basedir restriction fcgi und lighttpd

[snowball]

Hallo zusammen,
ich beschäftige mich grade mit der Konfiguration vom lighttpd in Verbindung mit FastCGI. Eines der vielen Probleme vor denen ich grade stehe ist die Überlegung: Wie schaffe ich es, das ein User zwar Dateien zu seinem vhost hochladen darf, aber die Dateien nichts von meinem Server auslesen können?

Code: Select all

<? echo file_get_contents("/etc/passwd"); ?>

Mein Apache kennt dafür die open_basedir restriction. Mein Lösungsansatz war eigentlich der safe_mode, aber da der ja demnächst abgeschafft werden soll, hilf mir das auch nur kurzfristig.

Hat vielleicht jemand von euch einen Tipp für mich? Bin atm ein wenig ratlos.

Cheers,
Jochen

[duergner]

open_basedir ist keine Einstellung des Apache sondern ein Eintrag in der php.ini. Somit geht das auch unter lighttpd. Wenn du FCGI fährst gibst du ja sowieso eine eigene php.ini für jeden VHost an. EInfach dort den open_basedir eintragen und gut ist. Sei aber gewarnt, das open_basedir nicht wirklich das kann, was es verspricht. Zwingend an open_basdir hält sich nur der PHP Core. Die MySQl Extension hatte hier (zumindest in der Vergangenheit) schon mal anders gearbeitet.

[snowball]

open_basedir ist keine Einstellung des Apache sondern ein Eintrag in der php.ini. Somit geht das auch unter lighttpd.

Arg, natürlich. Hast mich erwischt. Ich kenne das nur so, das der Eintrag als php value in den vhost des Indianers eingetragen wird. Deshalb habe ich dummerweise nicht an die php.ini gedacht.

Wenn du FCGI fährst gibst du ja sowieso eine eigene php.ini für jeden VHost an.

Ähh mache ich das? Wusste ich bis grade garnicht :oops:

Sei aber gewarnt, das open_basedir nicht wirklich das kann, was es verspricht. Zwingend an open_basdir hält sich nur der PHP Core. Die MySQl Extension hatte hier (zumindest in der Vergangenheit) schon mal anders gearbeitet.

Was ist denn deiner Meinung nach das ultimative Sicherheitsfeature? (Ausser chroot für jeden vhost :lol: )

Danke.

[rootsvr]

Was ich mal loswerden will: Es wird immer: "openbasedir ist auch nicht das Wahre" o.ä. geredet.

Soweit ich weiß ist Openbasedir aber eine der Lösungen (einzigste?) die Effektiv sowas verhindern können. Alle anderen Kommentare waren chroot, oder "Rechte richtig setzen"

Das sind zwar nette Ideen, aber a) oft etwas oversized/kompliziert (chroot) oder allgemein dahingeknallt.
Wie man zumindest die Rechte richtig setzen sollteist mir nicht klar, bzw wurde auch bisher nicht verraten.

Meine Bemühungen (einen nicht chrooteten) Server nur mit rechten Einzuschränken sind kläglich gescheitert.

Ne Alternative zu Openbasedir gibt es Imho nicht, also ist das der Weg den mal gehen sollte.. nur weil mal nen Airbag früher nen Fehler hatte fährt man ja trotzdem nicht ohne.

Blindes vertrauen in Software und sich nicht über Fehler zu informieren ist immer falsch, egal was man einsetzt. Und biosher sind soweit ich das gefunden hab die Openbasedir Lücken jka geschlossen worden, oder?

[duergner]

Ich setze selbst auch open_basedir ein, da alle anderen Lösungen einfach nicht gut genug skalieren. Eine Alternative wären IMHO noch Sachen wie SELinux, etc.

Ich wollte nur drauf hinweisen, dass man sich mit open_basedir nicht in falscher Sicherheit wiegen sollte. Und sinnvolle Rechte auf die Homeverzeichnisse sollten halt dabei sein. In der /etc/passwd, /etc/shadow sollten ja i.d.R. sowieso keine interessanten Sachen drinnen stehn. Wenn man den SSH Login auf Keys beschränkt und su nur für bestimmte Nutzer zulässt hat man meiner Meinung nach schon eine gewisse Sicherheit. Natürlich immer gesetzt den Fall, dass das System auch sonst up2date ist.

[braindead]

ich hab mich noch nicht so wirklich mit dem problem beschäftigt aber kann sich lighttpd nicht selber chrooten (mit server.chroot)? Das würde doch das Problem beheben oder?

[Joe User]

aber kann sich lighttpd nicht selber chrooten (mit server.chroot)? Das würde doch das Problem beheben oder?

Ja. Nein, denn die (F)CGI-Prozesse laufen trotzdem ausserhalb des Chroots...

[Roger Wilco]

Ja. Nein, denn die (F)CGI-Prozesse laufen trotzdem ausserhalb des Chroots...

Du kannst die FastCGI-Prozesse auch in eine chroot-Umgebung packen. Auf Wunsch sogar für jeden Benutzer eine eigene, siehe `spawn-fcgi -h` bzw. `man spawn-fcgi`. Der Nachteil (oder je nachdem, wie man es sieht auch Vorteil) ist, dass die FastCGI-Prozesse nicht mehr automatisch vom lighttpd gestartet werden. Das lässt sich mit einem entsprechenden Initskript aber verschmerzen.

[bfrackie]

Mein Apache kennt dafür die open_basedir restriction. Mein Lösungsansatz war eigentlich der safe_mode, aber da der ja demnächst abgeschafft werden soll, hilf mir das auch nur kurzfristig.

ich will hier mal ein gerücht richtig stellen: safe_mode wird in PHP6 abgeschafft (bis dahin vergeht ja auch noch ne weile), allerdings hat safe_mode nichts mit open_basedir zu tun. man kann open_basedir nutzen, ohne safe_mode eingeschaltet haben.

Bart

[snowball]

Mein Apache kennt dafür die open_basedir restriction. Mein Lösungsansatz war eigentlich der safe_mode, aber da der ja demnächst abgeschafft werden soll, hilf mir das auch nur kurzfristig.

ich will hier mal ein gerücht richtig stellen: safe_mode wird in PHP6 abgeschafft (bis dahin vergeht ja auch noch ne weile), allerdings hat safe_mode nichts mit open_basedir zu tun. man kann open_basedir nutzen, ohne safe_mode eingeschaltet haben.

Bart

Da hast du schon recht. Aber bei meiner Suche nach einem "Ersatz" von open_basedir hat mir der safe_mode nicht geholfen. Wenn ich jetzt schon weiß, das er abgeschafft werden soll, werde ich mein
produktives System doch nicht einfach umstellen. Was soll ich denn dann machen, wenn es soweit ist?

[bfrackie]

sag mir bitte, wo steht das open_basedir abgeschafft wird?

[snowball]

sag mir bitte, wo steht das open_basedir abgeschafft wird?

Ähh, wo habe ich das denn geschrieben. Safe_mode wird abgeschafft und das steht http://de3.php.net/manual/en/features.safe-mode.php hier

[bfrackie]

sag mir bitte, wo steht das open_basedir abgeschafft wird?

Ähh, wo habe ich das denn geschrieben. Safe_mode wird abgeschafft und das steht http://de3.php.net/manual/en/features.safe-mode.php hier

sorry, das hatte ich so aus dem 1. post "rausgelesen". du kannst bei jeder php-verson (egal ob lighthttpd oder apache oder commandline) der php.ini dein open_basedir mitgeben. ist zwar nicht 100% sicher, aber für die skriptkiddies reicht es aus. schade ist, das mit safe_mode die "safe_include_exec_dirs" verschwinden, dafür wird es aber wohl eine alternative wie open_basedir geben.

[snowball]

du kannst bei jeder php-verson (egal ob lighthttpd oder apache oder commandline) der php.ini dein open_basedir mitgeben. ist zwar nicht 100% sicher, aber für die skriptkiddies reicht es aus. schade ist, das mit safe_mode die "safe_include_exec_dirs" verschwinden, dafür wird es aber wohl eine alternative wie open_basedir geben.

Jepp, hat duergner ja auch schon gesagt. Ich suche jetzt nur noch eine elegante Möglichkeit, für jeden vhost ein eigene php.ini zu nutzen. Das einzige was ich dazu bis jetzt gefunden habe basiert auf den entsprechenden Dateibereichtigungen für den vhost. Was mir daran nicht gefällt ist, das ich für jeden vhost ein php starten muss... mit entsprechendem startskript und was sonnst noch so dazu gehört. da muss es doch was besseres geben. Oder suche ich mal wieder die "eierlegende wollmilchsau"?

[Joe User]

Du kannst die FastCGI-Prozesse auch in eine chroot-Umgebung packen. Auf Wunsch sogar für jeden Benutzer eine eigene, siehe `spawn-fcgi -h` bzw. `man spawn-fcgi`. Der Nachteil (oder je nachdem, wie man es sieht auch Vorteil) ist, dass die FastCGI-Prozesse nicht mehr automatisch vom lighttpd gestartet werden. Das lässt sich mit einem entsprechenden Initskript aber verschmerzen.

Ich weiss, daran arbeite ich ja seit gestern ;)

[braindead]

Wenn du fertig bist damit würde mich interessieren wie du das gelöst hast. Kannst uns ja dann mal ein HowTo zukommen lassen. Wenn du magst kann ich dir mal schicken wie ich das bisher mache (sehr eingeschränkt auf einen User).

[Joe User]

Ich muss noch drei kleinere Bugs fixen und die Konfiguration von mod_proxy überarbeiten, dann ist zumindest das erste Alpha-Release des Scripts (Gentoo-Version) fertig.