Confixx - Wie funktioniert das eigentlich?

[Peter Thomassen]

Hi,
viele von euch kennen sicherlich die Serverkonfigurationssoftware
Confixx. Gut, Serverkonfiguration ist zu viel, aber man kann im-
merhin Wiederverkäufer und Endkunden erstellen und einigermaßen
vernünftig verwalten.

Dazu hab ich ein paar Fragen:

• Wie funktioniert das eigentlich? Ich habe gehört, der PHP-Teil
    von Confixx schreibt die auszuführenden Vorgänge in eine Daten-
    bank, ein anderes Programm liest und führt sie aus. Stimmt das
    so?

• Warum muss das eigentlich teilweise auf PHP, teilweise auf einer
    anderen Sprach (Perl?) basieren? Klar, um POP3-Postfächer usw.
    anzulegen, ist das klar; man muss ja Benutzer auf dem Server an-
    legen. Aber um einen Endkunden anzulegen - eigentlich werden da
    doch nur ein Verzeichnis angelegt, ein neuer Virtualhost in die
    httpd.conf geschrieben, die Kundendaten in eine Datenbank, und
    ... ja, und? Wozu braucht man da eine andere Sprache? Apache
    lässt sich ja via Zeitsteuerung neu starten.

• Jemand hat mir gesagt, wenn das nur auf PHP basieren würde,
    könnte der Endkunde leicht Rootzugriff erhalten. Stimmt das,
    und, wenn ja, aus welchem Grund denn?

Danke für eure Informationen,
Peter

[Calocybe]

Moin!

• Jemand hat mir gesagt, wenn das nur auf PHP basieren würde,
    könnte der Endkunde leicht Rootzugriff erhalten. Stimmt das,
    und, wenn ja, aus welchem Grund denn?

Ich weiss zwar nicht, was Confixx ist, aber das letzte stimmt vermutlich so halb. Es ist so, dass der Apache und alle von ihm gestarteten Kindprozesse normalerweise als ein User laufen, der nicht viel Schaden im System anrichten kann (also insbesondere nicht root ist). Um Benutzer anzulegen, httpd.conf zu aendern und einige andere Dinge zu machen, braucht man aber root-Rechte. Wuerde man das jetzt direkt das PHP Script machen lassen wollen, muesste der Webserver selbst als root laufen, und das ist eine *verdammt* schlechte Idee. Denn sobald eine Sicherheitsluecke irgendwo ist und jemand nutzt die aus, wuerde er root-Zugriff bekommen. Laeuft der Webserver aber als nobody, kann ein Intruder nur soviel kaputt machen wie eben dieser nobody (im Idealfall nichts).

Das andere Zeug, in DB schreiben, Verzeichnisse anlegen und so, nun vielleicht ist das im Konzept so vorgesehen, dass das auch root oder jemand anderes macht. Wuerde nobody da selbst machen, dann gehoeren dem hinterher auch die Verzeichnisse, d.h. er kann alles damit machen was er will. Und je mehr Daten dem nobody gehoeren, umso maechtiger wird er (und umso weniger ist er "nobody"). Jetzt koennte ein Einbrecher viel mehr kaputt machen. Dann nuetzt es auch nichts mehr, den Webserver unter so einem Account laufen zu lassen, da kann man dem Apachen auch gleich root-Rechte geben, da kracht's dann wenigstens richtig. ;-)

HTH && So long

--
Alle Verallgemeinerungen sind falsch.

[Michael Schröpl]

Hi Calocybe,

Um Benutzer anzulegen, httpd.conf zu aendern und einige andere Dinge
zu machen, braucht man aber root-Rechte.

auf 'meinen' UNIX-Rechnern gibt es eine Benutzerkennung "apache", welche sich um alles kümmert, was den Apache angeht.
Diese ist owner der httpd.conf, und sie kann auch den Apache starten und stoppen.

Einzige Notwendigkeit für root: chmod u+s für das httpd-binary.
(Und eine group-Definition, die es dem Benutzer "apache" als einzigem erlaubt, dieses Programm zu starten, und _kein_ x-Bit für "others".)

Viele Grüße
      Michael

[Calocybe]

Moin Michael!

auf 'meinen' UNIX-Rechnern gibt es eine Benutzerkennung "apache", welche sich um alles kümmert, was den Apache angeht.

Yoh, auf meinem heisst er httpd. Dadurch lassen sich die Rechte auf die Verzeichnisse, die geservt werden, viel besser setzen. Aber ich bin hier mal von der Defaultinstallation ausgegangen, wo die executable und httpd.conf root gehoert und der server unter nobody laeuft. Das erschien mir fuer die Erklaerung guenstiger. ;-)

Diese ist owner der httpd.conf, und sie kann auch den Apache starten und stoppen.

Mmh, wenn Du das so brauchst und das anderweitig gut genug abgesichert ist, warum nicht. Allgemein halte ich es aber nicht fuer empfehlenswert, die Webserverconfig ueber's Internet editierbar zu machen.

Einzige Notwendigkeit für root: chmod u+s für das httpd-binary.
(Und eine group-Definition, die es dem Benutzer "apache" als einzigem erlaubt, dieses Programm zu starten, und _kein_ x-Bit für "others".)

Meinst Du
(perms / owner / group / name) = (-rwsr-x--- / httpd / apache / httpd) ?

So long

--
Wenn Wahlen etwas ändern könnten, würden sie sofort verboten werden.

[Michael Schröpl]

Hi Calocybe,

Diese ist owner der httpd.conf, und sie kann auch den
Apache starten und stoppen.
Allgemein halte ich es aber nicht fuer empfehlenswert,
die Webserverconfig ueber's Internet editierbar zu machen.

Ist sie das denn?
(Der Apache _läuft_ selbst durchaus unter "nobody" ... nicht unter "apache". Ich will einfach nur nicht, daß der "Apache-Operator" das root-Passwort braucht.)

(perms / owner / group / name) = (-rwsr-x--- / httpd / apache / httpd) ?

Fast - als owner brauche ich "root" für das binary. (Nur um Port 80 binden zu dürfen - mit Ports > 1024 ginge das auch ganz ohne.)

Viele Grüße
      Michael

[Calocybe]

Moin!

Ist sie das denn?
(Der Apache _läuft_ selbst durchaus unter "nobody" ... nicht unter "apache". Ich will einfach nur nicht, daß der "Apache-Operator" das root-Passwort braucht.)

Ach so. Ich hatte verstanden, Du wuerdest die conf ueber CGI Scripts aendern. Das ist was anderes.

(perms / owner / group / name) = (-rwsr-x--- / httpd / apache / httpd) ?

Fast - als owner brauche ich "root" für das binary. (Nur um Port 80 binden zu dürfen - mit Ports > 1024 ginge das auch ganz ohne.)

Ja, meinte auch root als owner. Wer weiss, was ich wieder durcheinander gebracht habe.

So long

--
Wenn Wahlen etwas ändern könnten, würden sie sofort verboten werden.