suPHP + externe binaries wie z.B. ImageMagick

[Anonymous]

Hallo,

was wäre die praktikabelste Lösung um seinen Kunden z.B. ImageMagick zur Verfügung zu stellen, trotz suPHP?

Ich denke es gibt mehrere Möglichkeiten, mit denen ich mich persönlich aber nicht anfreunden kann:

a) man gibt den Usern Zugriff per OpenBasedir für die direkten globalen Pfad
b) man gibt dem User in seinem jeweiligen DocRoot einen extra bin/ Pfad wo die binaries drin liegen (jeweils mit chmod/chown für ihn angepasst)
c) man extrahiert die binaries und macht sie in einem übergeordneten Ordner, über dem jeweiligen DocRoot global verfügbar


mir erscheint da c) immernoch am besten. Wie seht ihr das? :)

[r00ty]

hmmm also ich finde deine Frage irgendwie komisch
zuersteinmal lese ich da dass du suPHP laufen hast, also hast du doch gar keine OpenBasedir beschränkungen, das hast du nur wenn es als MOD_PHP läuft.
und da mit suPHP ImageMagick unter den user-rechten läuft stellt das doch auch kein Problem dar (ausser es kommt ein root-exploit raus, aber das Problem haste eh immer).
Ich verstehe die Problematik noch nicht die du hast....

[Anonymous]

hmmm also ich finde deine Frage irgendwie komisch
zuersteinmal lese ich da dass du suPHP laufen hast, also hast du doch gar keine OpenBasedir beschränkungen, das hast du nur wenn es als MOD_PHP läuft.

Natürlich hab ich die nach wie vor (als zusätzliche Sicherheit .. ich habe für jeden User einen einzelnen suPHP_ConfigPath gesetzt und so eine eigene php.ini mit einer basedir Beschränkung .. außerdem mache ich das so, damit ich spezifische upload_tmp's sowie auch session directories festlegen kann)

und da mit suPHP ImageMagick unter den user-rechten läuft stellt das doch auch kein Problem dar (ausser es kommt ein root-exploit raus, aber das Problem haste eh immer).
Ich verstehe die Problematik noch nicht die du hast....

Und da ich wie oben bereits gesagt eine open_basedir beschränkung habe (die ich auch so nicht lösen möchte) habe ich eben das Zugriffsproblem auf global liegende binaries.

[r00ty]

na dann wist du nicht um Variante c rumkommen
ich hatte irgendwann auch mal was mit Hardlinks gelesen, die du dafür einsetzen könntest, aber die tun ja nicht auf jedem FileSystem

[sascha]

Open_basedir braucht man bei php als cgi eigentlich nicht. Vorausgesetzt man hat seine Datei- und Verzeichnisrechte richtig vergeben. Wenn du CGI per SuExec erlaubst hast du so ein Feature ja normalerweise auch nicht und da stört sich auch keiner dran. Warum also php unnötig einschränken? Mach das open_basedir raus (oder erweitere es auf /bin und /usr/bin, oder ein eigenes php-bin mit den gewünschten Binaries) und fertig. Das eigene Session und Tempdir kannst du ja trotzdem lassen.

[Anonymous]

Open_basedir braucht man bei php als cgi eigentlich nicht. Vorausgesetzt man hat seine Datei- und Verzeichnisrechte richtig vergeben. Wenn du CGI per SuExec erlaubst hast du so ein Feature ja normalerweise auch nicht und da stört sich auch keiner dran.

Was verstehst du unter CGI? Ein PHP Script ist genauso CGI und was sonst sollte man noch ausführen können? Zumal ich suPHP und kein suEXEC einsetze.

Warum also php unnötig einschränken? Mach das open_basedir raus

Nein .. user sollen eben nicht einfach was ausführen können so z.B. 'wget' was ja auch global read/executeable ist.

(oder erweitere es auf /bin und /usr/bin, oder ein eigenes php-bin mit den gewünschten Binaries) und fertig. Das eigene Session und Tempdir kannst du ja trotzdem lassen.

Ja ich kenne meine Möglichkeiten .. mir ging es nur um primäre Vorzüge der User dieses Forums und etwaige Vor/Nachteile von den verschiedenen gelisteten Varianten.

[sascha]

Was verstehst du unter CGI? Ein PHP Script ist genauso CGI und was sonst sollte man noch ausführen können? Zumal ich suPHP und kein suEXEC einsetze.

PHP kann natürlich auch ein CGI sein. Ich meinte hier vorallem Perl und Shellscripte. Sowas lässt man für gewöhnlich über SuExec laufen. Benutzt du denn auf deinem Server keine Perl Scripte? Wie sicherst du diese ggf.?

Nein .. user sollen eben nicht einfach was ausführen können so z.B. 'wget' was ja auch global read/executeable ist.

wget ist ja auch ein sehr gefährliches Programm... Führen deine User denn nur PHP Scripte aus? Kein Perl, Python, Shell, whatever? Wenn du nicht willst dass man bestimmte Programme nutzen kann, dann ändere die Rechte dafür. So mache ich das übrigens bei mir.

Ja ich kenne meine Möglichkeiten .. mir ging es nur um primäre Vorzüge der User dieses Forums und etwaige Vor/Nachteile von den verschiedenen gelisteten Varianten.

Meine Vorzüge kennst du ja jetzt ;).

[Joe User]

http://www.rootforum.org/forum/viewtopi ... 518#163518

[Anonymous]

PHP kann natürlich auch ein CGI sein. Ich meinte hier vorallem Perl und Shellscripte. Sowas lässt man für gewöhnlich über SuExec laufen. Benutzt du denn auf deinem Server keine Perl Scripte? Wie sicherst du diese ggf.?

wget ist ja auch ein sehr gefährliches Programm... Führen deine User denn nur PHP Scripte aus? Kein Perl, Python, Shell, whatever? Wenn du nicht willst dass man bestimmte Programme nutzen kann, dann ändere die Rechte dafür. So mache ich das übrigens bei mir.

Nein die User sollen nur PHP Scripte ausführen dürfen sprich kein Perl, Shellscripte etc. und in diesen auch keinerlei Programme wie z.B. wget (ich frage mich eh gerade wie man es unterbinden kann, z.b. einen sshd lokal vorkompiliert laufen zu lassen, um dann z.B. so etwaige Scripts / Dateien zu manipulieren, außer man begrenzt die maximale Prozesszeit des Users auf z.B. 30 Sekunden)

[sascha]

Prozesslaufzeit usw. sollte man eh limitieren. Vor dem sshd schützt dich GRSecurity (Socket restrictions).

[Anonymous]

Vor dem sshd schützt dich GRSecurity (Socket restrictions).

Nun wie restriktiere ich das am besten? Die einzige Gemeinsamkeit was Gruppenzugehörigkeit der einzelnen User angehst ist, dass alle in 'ftpuser' sind, ergo kann ich die Gruppe ftpuser in soweit über socket restrictions restriktieren, dass diese keine server sockets mehr haben dürfen bzw. was ist ratsam? Sicherlich wäre es auch möglich einen server_socket als client_socket zu tarnen aber jegliche sockets möchte ich dann doch nicht restriktieren

[sascha]

Du kannst die User ja nach Bedarf zusätzlich in eine der 3 möglichen Gruppen stecken.

[Anonymous]

hm mir ist aufgefallen, dass trotz open_basedir Beschränkung der User immernoch *nach unten* sprich z.B. in /usr/bin/ kann .. i

d.h. man erreicht nur eine halbwegs anständige Absicherung im Bereich für shared Webhosting, wnen man safe_mode, open_basedir und suexec/suphp im Einsatz hat?

[superuser1]

Hi...

auch ich würde dir zu PHP als CGI und suPHP bzw. suEXEC für Perl/CGI raten - alles andere wäre dann über die Rechteverwaltung abzusichern. (entsprechendes Setzen der Restriktionen in den Konfigurationsdateien vorausgesetzt)

Zudem würde ich dir erstmal zum Testen im 'Trockendock' raten, damit du die entsprechenden Konfigurationen überprüfen und entsprechend anpassen kannst.

Letztendlich könntest du dann versuchen, deine eigenen Sicherheitsvorkehrungen zu durchbrechen, z.B. durch geschickt programmierte Skripte oder Ã?hnlichem - das sollte dir bei der Fehlersuche und Systemoptimierung ein ganzes Stück weiterhelfen.

:roll:

PS: SafeMode ist meiner Meinung nach bei durchdachter Rechtestruktur/PHP-Konfiguration nicht mehr zwingend notwendig.

[Anonymous]

Hi...

auch ich würde dir zu PHP als CGI und suPHP bzw. suEXEC für Perl/CGI raten - alles andere wäre dann über die Rechteverwaltung abzusichern. (entsprechendes Setzen der Restriktionen in den Konfigurationsdateien vorausgesetzt)

PS: SafeMode ist meiner Meinung nach bei durchdachter Rechtestruktur/PHP-Konfiguration nicht mehr zwingend notwendig.

Halte ich für totalen Schwachsinn denn, alleine suphp beschraenkt ja nur die Ausfuehrbarkeit des
scriptes, und nicht die resourcen auf die das script
zugreift. also könnte man doch locker nen dateibrowser per
php basteln oder sich z.b. die /etc/passwd anzeigen lassen.

Natuerlich könnte man mit chmod dagegenwirken .. aber was ist praktikabler .. ALLE files die zum vermeintlichen missbrauch führen könnten die globalen Rechte entziehen (was dann wiederum Probleme für einen User auf der shell gibt) oder das jeweilige CGI zu "jailen" mittels PHP Direktiven Settings ... natürlich dann das 2.

durch verschiedene Tests und Abwägung bin ich eindeutig zu dem Schluss gekommen, dass man nur eine halbwegs vernünftige Lösung erreicht, indem man Safe_mode + suphp/suexec + openbasedir/upload_tmp_dir/upload_session_dir direktiven verwendet

[Joe User]

man acl

[superuser1]

Hi...

Halte ich für totalen Schwachsinn denn, alleine suphp beschraenkt ja nur die Ausfuehrbarkeit des scriptes, und nicht die resourcen auf die das script zugreift.

Das halte ich für, um deinen lockeren Ton zu vermeiden (ich glaube nicht dass das hier ein Forum für Schwachsinnige ist), für eine zumindest sehr fragwürdige Aussage. Ã?berleg dir nochmal, was suPHP eigentlich tut...

...indem man Safe_mode + suphp/suexec + openbasedir/upload_tmp_dir/upload_session_dir direktiven verwendet

Und wenn du jetzt noch deine Rechte richtig gesetzt hast und dann evtl. noch zu Fuß ein paar gefährliche Funktionen 'disablest', dann kannst du auf Safe_Mode verzichten.

:roll:

[Anonymous]

Hi...

Halte ich für totalen Schwachsinn denn, alleine suphp beschraenkt ja nur die Ausfuehrbarkeit des scriptes, und nicht die resourcen auf die das script zugreift.

Das halte ich für, um deinen lockeren Ton zu vermeiden (ich glaube nicht dass das hier ein Forum für Schwachsinnige ist), für eine zumindest sehr fragwürdige Aussage. Ã?berleg dir nochmal, was suPHP eigentlich tut...

...indem man Safe_mode + suphp/suexec + openbasedir/upload_tmp_dir/upload_session_dir direktiven verwendet

Und wenn du jetzt noch deine Rechte richtig gesetzt hast und dann evtl. noch zu Fuß ein paar gefährliche Funktionen 'disablest', dann kannst du auf Safe_Mode verzichten.

:roll:

Fragwürdig? Ein Fakt ist nicht fragwürdig...

suPHP is a tool for executing PHP scripts with the permissions of their owners.

.. Und es gibt kein *Rechte richtig gesetzt* .. man müsste praktisch allen potentiellen Gefahren die binaries im allgemeinen darstellen die globalen/world Rechte entziehen .. was wiederum Schwachsinn ist, da dnan lokale Shell user auf diese nichtmehr zugreifen können.

Ergo ist deine obige Aussage à la "suPHP ohne safe_mode in Verbindung mit *Rechte setzen* = sicher genug" einfach falsch

[oxygen]

.. Und es gibt kein *Rechte richtig gesetzt* .. man müsste praktisch allen potentiellen Gefahren die binaries im allgemeinen darstellen die globalen/world Rechte entziehen .. was wiederum Schwachsinn ist, da dnan lokale Shell user auf diese nichtmehr zugreifen können.

Ergo ist deine obige Aussage à la "suPHP ohne safe_mode in Verbindung mit *Rechte setzen* = sicher genug" einfach falsch

Dann gibts du den Shell User halt Gruppenrechte auf die entsprechenden Binarys. Außerdem, wenn du sowieso Shell User hast, warum machst du dir dann Gedanken über PHP?

[Anonymous]

.. Und es gibt kein *Rechte richtig gesetzt* .. man müsste praktisch allen potentiellen Gefahren die binaries im allgemeinen darstellen die globalen/world Rechte entziehen .. was wiederum Schwachsinn ist, da dnan lokale Shell user auf diese nichtmehr zugreifen können.

Ergo ist deine obige Aussage à la "suPHP ohne safe_mode in Verbindung mit *Rechte setzen* = sicher genug" einfach falsch

Dann gibts du den Shell User halt Gruppenrechte auf die entsprechenden Binarys. Außerdem, wenn du sowieso Shell User hast, warum machst du dir dann Gedanken über PHP?

hm nein ich habe keine Lust alle möglichen potentiellen Gefahren die von binaries ausgehen könnten neu zu chmoden .. das ist unpraktikabel!

Ich benutze einfach safe_mode .. alles andere wäre mir imho von den obig genannten Gründen her zu unsicher..