Hallo,
wirkt sich eigentlich die Apache Option "OPTIONS Symlink" in irgendeiner Weise auf die verbotenen Symlinks unter Suhosin, bzw steht das in Verbindung mit der PHP Version Symlink() ?
Hintergrund ist der: Da viele CMS mit einer htaccess Datei kommen, wo die OPTIONS Direktive frei sein muss, da Sie innerhalb der htaccess Symlinks setzen, besteht bei mir folgende Überlegung.
Die Direktive OPTIONS freischalten, so dass die "vhostler" ihre OPTIONS in einer htaccess Datei gebrauchen können. Dann wäre ja Symlinks frei. Jetzt aber Suhosin rauf, da sind ja Symlinks verboten.
Macht das alles irgendeinen Sinn? In der Doku von Suhosin steht jetzt auch noch, gerade wenn open_basedir genutzt wird, setze keine Symlinks. Bezieht sich das auf PHP oder auf die Apache Direktive?
gruß cirox
suhosin symlink() Options Symlink
-
- Posts: 5923
- Joined: 2004-05-23 12:53
Re: suhosin symlink() Options Symlink
Suhosin greift nur bei PHP-Skripten. Auf die Funktionsweise des Apache httpd selbst hat das keinen Einfluss.
-
- Posts: 212
- Joined: 2006-05-08 23:20
- Location: Berlin
Re: suhosin symlink() Options Symlink
ok, das heisst das Symlinks per PHP nicht möglich sind. Wenn ich jetzt aber zum Beipiel Typo3 installiere und die Sourcen per Symlink mit dem Programm verbinde wäre das egal.
Jetzt ist meinetwegen per htaccess Datei erlaubt OPTIONS zu überschreiben. Mal abgesehen davon dass CGI eh erlaubt ist könnte ja der user "symlinks" (FollowSymlinks) erlauben. (Symbolische Links innerhalb des Verzeichnisses werden aufgelöst).
Insofern kann doch da gar nichts passieren, dass der user irgendwie ins System reinkommt, da ja symlinks per PHP verboten sind und der user ja per FTP keine Links setzen kann. Jetzt könnte er natürlich mit ner php Shell arbeiten. Mit dieser kann er er doch dann wieder ins System rein unter Umständen?
Das Worst Case Scenario ein Link auf /etc/password wird also nicht durch Suhosin verhindert ..... (zumindest in der Standardeinstellung)
Also ist es doch gefährlich die FollowSymlinks zu erlauben und es wäre besser FollowSymlinks IF Owner Match zu setzen und OPTIONS per htaccess für die User zu sperren.
Irgendwie gehts noch nicht richtig bei mir in meinen Kopf rein.
Mal davon abgesehen müsste man noch mod_sec chrooten, openbase_dir, etc. ...
Jetzt ist meinetwegen per htaccess Datei erlaubt OPTIONS zu überschreiben. Mal abgesehen davon dass CGI eh erlaubt ist könnte ja der user "symlinks" (FollowSymlinks) erlauben. (Symbolische Links innerhalb des Verzeichnisses werden aufgelöst).
Insofern kann doch da gar nichts passieren, dass der user irgendwie ins System reinkommt, da ja symlinks per PHP verboten sind und der user ja per FTP keine Links setzen kann. Jetzt könnte er natürlich mit ner php Shell arbeiten. Mit dieser kann er er doch dann wieder ins System rein unter Umständen?
Das Worst Case Scenario ein Link auf /etc/password wird also nicht durch Suhosin verhindert ..... (zumindest in der Standardeinstellung)
Also ist es doch gefährlich die FollowSymlinks zu erlauben und es wäre besser FollowSymlinks IF Owner Match zu setzen und OPTIONS per htaccess für die User zu sperren.
Irgendwie gehts noch nicht richtig bei mir in meinen Kopf rein.
Mal davon abgesehen müsste man noch mod_sec chrooten, openbase_dir, etc. ...
-
- Posts: 391
- Joined: 2006-09-05 21:12
- Location: Berlin
Re: suhosin symlink() Options Symlink
Hallo,
du hast deine Lösung doch bereits: FollowSymlinksIfOwnerMatch
Wenn der unbedingt einen Symlink auf /etc/passwd machen will, soll er doch. Mal schauen wie weit er kommt, abgesehen davon, dass er die eh nicht lesen darf, wenn die Rechte richtig stehen ;)
Gruß
dtdesign
du hast deine Lösung doch bereits: FollowSymlinksIfOwnerMatch
Wenn der unbedingt einen Symlink auf /etc/passwd machen will, soll er doch. Mal schauen wie weit er kommt, abgesehen davon, dass er die eh nicht lesen darf, wenn die Rechte richtig stehen ;)
Gruß
dtdesign
-
- Posts: 212
- Joined: 2006-05-08 23:20
- Location: Berlin
Re: suhosin symlink() Options Symlink
so läufts ja auch, bloss im Produktivbetrieb stressig. Du weisst ja, jedes 2. CMS und Co hat ne htaccess Datei mit ner OPTIONS Direktive drin und das gibt dann dann immer nen schönen 500 error.dtdesign wrote:Hallo,
du hast deine Lösung doch bereits: FollowSymlinksIfOwnerMatch
Naja die Frage ist doch was kann FollowSymlinks für einen Schaden anrichten im System, bei openbasedir, suhosin, mod_sec .... Klar für nen Hacker kein Problem, aber so im Prinzip halt gesehen. Mir reichts schon, wenn einer ne c99 Shell hochlädt. Wär da nicht mod_sec sähe es noch finsterer aus. Jedenfalls für mich.dtdesign wrote: Wenn der unbedingt einen Symlink auf /etc/passwd machen will, soll er doch. Mal schauen wie weit er kommt, abgesehen davon, dass er die eh nicht lesen darf, wenn die Rechte richtig stehen ;)
-
- Administrator
- Posts: 2639
- Joined: 2004-01-21 17:44
Re: suhosin symlink() Options Symlink
Die /etc/passwd darf jeder lesen (bzw. muss von jedem gelesen werden können), sonst könnte man sich schlecht einloggen (deshalb kam ja irgendwann auch einer auf die Idee, da keine Passwörter mehr reinzuschreiben, sondern die in die /etc/shadow zu verfrachten).dtdesign wrote:Wenn der unbedingt einen Symlink auf /etc/passwd machen will, soll er doch. Mal schauen wie weit er kommt, abgesehen davon, dass er die eh nicht lesen darf, wenn die Rechte richtig stehen
-
- Posts: 391
- Joined: 2006-09-05 21:12
- Location: Berlin
Re: suhosin symlink() Options Symlink
@jfreund: Webspacekunden benötigen für gewöhnlich keine Shell, also /bin/false und dann koennen wir direkt die Rechte ändern.
Zum Thema: Wenn FollowSymlinksIfOwnerMatch bei dir scheitert, hast du Mist gebaut ;) Tatsache ist, dass ein Script beim erstellen einer Datei immer die selben Besitzerrechte weitervererbt. Ergo hast du die .htaccess nicht anständig mit chowner/chgrp bearbeitet!
Gruß
dtdesign
Zum Thema: Wenn FollowSymlinksIfOwnerMatch bei dir scheitert, hast du Mist gebaut ;) Tatsache ist, dass ein Script beim erstellen einer Datei immer die selben Besitzerrechte weitervererbt. Ergo hast du die .htaccess nicht anständig mit chowner/chgrp bearbeitet!
Gruß
dtdesign