chmod auf fernem Server

[Alexander (HH)]

Moin Moin!

Wenn das ein Shared Hosting Server ist, solltest Du mal ein ernstes Wort mit dem Provider wechseln, denn offensichtlich läuft der Webserver ohne suexec oder Equivalent.

Offenbar. Aber der wird wegen mir nicht seine VHost-Server-Einrichtung ändern.

Hast Du wegen des Problems mit dem Provider Kontakt aufgenommen? Wenn ja, ist das ein Grund mehr, dort wegzugehen.

Damit kann jeder Kunde mit eigenen CGIs überall da herumpfuschen, wo der Webserver-User (UID=30, GID=65534) Schreibrechte hat -- auch in Verzeichnissen anderer User.

Zum Beispiel, weil ein Kunden-CGI irgendwo Schreibrechte braucht und der Kunde stumpf chmod 777 gemacht hat. Sollte der Provider nicht reagieren, solltest Du über einen anderen Provider nachdenken, der seine Server sicher konfiguriert hat.

Nochmal: Andere Kunden können in Deinem Webspace rumpfuschen, und Du kannst im Webspace anderer Kunden herumpfuschen, weil der Hoster zu blöd ist, den Webserver richtig aufzusetzen.

Ohne suexec (oder vergleichbare Systeme) zu arbeiten, also trotz mehrerer Kunden für alle CGIs den selben Account zu benutzen, funktioniert nur, so lange der Provider den CGIs vertrauen kann, nichts böses zu tun. Sprich: So lange der Provider es den Kunden NICHT erlaubt, eigene CGIs zu benutzen.

Der plaudert ganz gewiss seine Setup-Details in der Paketbeschreibung aus ;)

Manche vielleicht schon. Vor allem aber kannst Du mal nachfragen ("Unter welchem Account laufen CGIs? Unter meinem oder einem Sammel-Account für alle Kunden?"). Oder nach einem c't-Artikel der letzten zwei oder drei Jahre suchen, in dem unter anderem genau diese Isolation der Kunden voneinander getestet wurde.

Es ist ein stink normaler Massenhoster.

Nein, ein unterdurchschnittlich kompetenter.

Und es war mir bekannt, dass Perl nur die Rechte von user nobody hat. Habe ich übrigens ja schon im übrigen thread gesagt.

Technisch präziser: Perl wird vom Webserver mit den Rechten des nobody-Users gestartet. An Perl selbst hängen keine Rechte, es erbt die Rechte desjenigen Prozesses, der es aufgerufen hat.

Für mich war das ein Versuch für einen Test, um das Unix-System etwas kennenzulernen. Das Auskommen bedeutet halt, dass mein CMS keine chmod-Fähigkeiten in nächster Zeit implementiert bekommt.

Und dass jeder andere Kunde Deine Daten manipulieren und ggf. löschen kann.

Ich bin mir nicht sicher, ob ein Setuid Wrapper Script die Lösung ist.

Nein, suexec ist "die" Lösung. Der setuid-Wrapper ist nur eine Krücke, so lange Dein Hoster das grundlegende Problem seiner Systemkonfiguration nicht begriffen und beseitigt hat.

Der setuid-Wrapper verhindert nicht, dass andere Kunden über den Webserver Deine Scripte aufrufen und unter Deinem Account laufen lassen. Er verhindert aber, dass andere Kunden Zugriff auf die Dateien bekommen, auf die nur Deine Scripte Zugriff haben sollen. Deine Scripte paranoid genug zu programmieren, dass sie nichts "versehentlich" ausplappern, ist ein vollkommen anderes Problem, dessen Lösung mit "#!/usr/bin/perl -T" beginnt.

Grund: Wenn ich das will, dann brauche ich den Wrapper für alle Scripte.

Nicht notwendigerweise. Du brauchst für jedes Script, dass auf nicht-öffentliche Daten im Dateisystem zugreifen will, einen individuellen Wrapper. Scripte, die nur auf öffentliche Daten zugreifen oder gar nicht weiter mit Deinem Teil des Dateisystems interagieren, können weiterhin unter dem nobody-Account laufen.

Und dann muss ich bei jedem Script auch noch jeweils die Schreibrechte zuerst mit chmod einstellen und wieder ausschalten.

Was will mir dieser Satz sagen?

Mit dem Wrapper arbeiten die Scripte unter Deinem Account, warum willst Du an Zugriffsrechten rumschrauben?

Erst dann kann ich überall die World-Rechte auf readonly setzen.

Denk über diesen Satz bitte mal nach: Du hast die Rechte für bestimmte Verzeichnisse so eingestellt, dass JEDER NUTZER der Maschine dort schreiben kann. Und das gefällt Dir wirklich?

Ich würde an Deiner Stelle lieber heute als morgen den Provider wechseln.

Ich sehe deshalb setuid als problematisch an. Wenn dir ein anderer einbricht hast du definitiv das grössere Problem.

Nein, das riesige Problem ist das aktuelle Setup des Webservers. suexec würde das Problem vollständig lösen.

Ein setuid-Wrapper erlaubt es jedem Benutzer, ein Programm unter Deinem Account auszuführen. Aber eigentlich willst Du das Programm nur dann ausführen, wenn es vom Webserver gestartet wird. Also wird eine der ersten Aktionen des Wrappers sein, getuid(), getgid(), geteuid() und getegid() aufzurufen und mit den erwarteten, fest encompilierten Werten zu vergleichen und bei Abweichngen das Programm sofort zu beenden.

Wenn Du Dir die Doku des suexec-Helfers des Apachen mal genauer ansiehst, wirst Du feststellen, dass der genau das macht -- eine paranoide Prüfung der Umgebung und der Aufrufparameter.

Einen gefakten Aufruf über den Webserver, z.B. durch ein anderes CGI, wirst Du kaum verhindern können. Das ist auch relativ unproblematisch, denn Dein Script wird ja alle Eingaben und das Environment ausreichend paranoid prüfen, bevor es Daten verarbeitet oder ausgibt. Du könntest natürlich prüfen, ob der Parent-Prozess wirklich der Webserver ist, aber das ist nicht 100% sicher. Ein böswilliges, fremdes CGI kann immer noch das Environment, STDIN und STDOUT manipulieren, bevor es sich selbst per exec() durch Dein Script / Wrapper ersetzt.

Beziehe mich darauf http://www.xav.com/scripts/help/setuid.html

Da lese ich extrem wenig zu setuid-Wrappern, nur viel Halbwissen und Cargo Cult. Das Bißchen, das da steht, ist ziemlich alt und ziemlich dumm. Denn genau die notwendigen Tests der realen und effektiven User- und Group-IDs fehlen. Richtig ist, dass Perl im Taint-Mode betrieben werden sollte, wenn man mit Daten aus unsicheren Quellen arbeitet. Falsch dagegen ist wieder, dass diese Seite dass nur für Scripte empfiehlt, die über setuid-Wrapper gestartet werden. Richtig ist der Link auf die perlsec-Dokumentation, schöner wäre allerdings gewesen, auf eine aktuelle Fassung, z.B. http://perldoc.perl.org/perlsec.html, statt auf eine fast zehn Jahre alte 5.6.0-Version. Falsch ist wiederum die Aussage, man müsse $ENV{'PATH'} löschen. Das ist lang und breit in der Doku beschrieben, und PATH ist nicht die einzige kritische Environment-Variable. Von dem dort ebenfalls empfohlenen CGIWrap kann ich nur abraten, das sieht aus wie ein mißglückter Versuch, suexec nachzubauen.

Alexander