xwolf: PHP & Sicherheit

Beitrag lesen

Hi,

[...]denn dann kann man mit suxec die PHP-Files allein fuer den Owner lesbar machen, anstelle fuer global.
was ist suxec? Wie muß ich das verstehen?

suexec ist das Apachemodul, das fuer virtuelle Hosts eine Changeroot-Umgebung macht, so dass Skripten ueber die Keunnung asugefuehrt werden,
die mittels
User USERNAME
Group GROUPNAME
in <VirtualHost> definiert sind

Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Bei mir läuft es als CGI und das erh gut, die einzigen beiden Einschränkungen bis heute waren das die PHP-Authentifiziereung nicht geht, und auch über htaccess keinen Einfluß auf PHP genommen werden kann. Sonst hatte ich dadurch bis heute keien Nachteile, oder was wäre Dir da was eklatantes bekannt?

Da ich PHP nur fuer Spielereien benutze nicht :)
Allerdings geht der angebliche Geschwindigkeitsvorteil von PHP
floeten, weil bei jedem neuen Aufruf das Skript neu geladen und interpretiert wird.
Also so, als ob man CGI ohne FastCGI benutzt.

Du aber auch nicht.
In der Doku von PHP steht genau zu dem Punkt, dass nur PHP ueber CGI in den Faellen bzgl Filesystem-Lesen hilft.
Aber man kann unter Linux doch überall strikte Rechte vergeben, wozu braucht PHP root-Rechte?

Von Root-Rechten hat niemand geredet.

Ganz im Gegenteil ist das Problem da, weil kein vernuenftiger Admin
den Apache als Root laufen laesst.

Die Hauptinstanz des Webservers und dessen Childs laufen unter der
kennung, die man mit USER und GROUP in der httpd.conf definiert.

Der User jedoch, der Webfiles anlegt, hat eine andere Userkennung und eine andere Group.
Da diese meistens nicht kommulieren (d.h. Apacheuser != User der Files
bearbeitet und Webservergroup != usergroup), bleibt dem Webseitenbastler nichts uebrig, als die Webfiles global lesbar zu machen.

So weit so gut.

Und nun ist ein dritter oder x weitere User auf dem Filesystem.

Was kann dieser tun? Richtig - per "cat <filename>" oder "less <filename>" einfach die global lesbare Datei anschauen.

Was nicht weiter schlimm ist, wenn es alles eh nur Gimmicks und oeffentliche Daten sind.
Problematisch nur, wenn in der php-File oder dessen Include irgendwo Datenbankzugaenge stehen.

Das Problem der PHP-Coder ist, dass sie noch immer
von Einzeluser-Systemen ausgehen. Deswegen kennen die einfach nicht das Problem bzw. es gibt keinen Druck da was zu machen.
Hä? PHP wird doch so gut wie nur auf größeren Webservern bei Massenhostern verwendet, und da wird wohl kaum jeder Kunde einen Einzeluser-System haben, oder? Schön wärs...

Eben deswegen hatte der c't-Artikel so eine relevanz.
Dedizierte Server sind nur wenig im Einsatz. Und taugliche Loesungen sind mir nur fuer BSD bekannt.
Das das ganze erst jetzt so langsam auftaucht, leigt auch daran, dass immer mehr Leute einen Shell-Zugang wollen und sich nicht mehr mit einem FTP-Zugang abspeisen lassen wollen (wobei FTP sowieso unsicher ist).

Natuerlich haben die c't-Leute verschwiegen, wie eine -machbare- Loesung fuer eine Low-Budget-Umgebung auszusehen haette....

Eine Loesung liegt darin, mit den Unixgruppen rumzuspielen.
Wobei man leider den leichtesten Weg, naemlich den Apacheuser zusammen mit allen einzelnen usern jeweil sin einer Gruppe zu tun, nicht funktioniert, wenn man mehr als 25 User hat. (Ein User kann nicht in mehr als 25 Gruppen sein).

Die Loesung die ich in Anwendung hab, beruht auf einen Mix aus Solaris-ACLs, gemounteten Bereichen, auf die nur spezielle User Zugriff haben,  einer allgemeinen Webmaster-Gruppe und (und das geht aber nur bei Unis oder Vereinen:) restriktive Benutzungsregeln in Bezug auf einen eigens zu beantragenden 'Webmaster-Zugang'.

Ciao,
  Wolfgang