@Michael-Huhn

Danke für die Rückmeldung. Ich habe zwei Drafts eingestellt. Ich muss nochmal in Ruhe schauen, ob ich was übersehen habe.

https://github.com/i-doit/knowledge-base/pull/1093
https://github.com/i-doit/scripts/pull/50

Was mir generell am meisten aufstößt, ist dass die DocumentRoot komplett mit Schreibrechten für den Apache ausgestattet wird. Auf der Seite vom Hardening wird dann mit Permissions und immutable Attribute das wieder gesichert.

Das macht IMHO wenig Sinn, dass man sichere Voreinstellungen des Systems (z.B. Owner root:root mit Context httpd_sys_content_t) aufweicht, um sie dann später umständlich wieder zu härten.

Ich bin ja ein Fan davon, gleich alles richtig und sicher zu installieren (dann kann man es auch gut als RPM verpacken) und nur auf die Verzeichnisse dem Webserver Schreibrechte zu geben, wo diese tatsächlich notwendig sind.

Aber dann kann man natürlich erstmal nicht den Web-Updater benutzen. Aber die sind aus Sicherheitsgesichtspunkten sowieso immer kritisch, wenn der Web-Update seinen eigenen Code aktualisieren will, sofern man keinen Umweg über ein Script geht, welches als root läuft (der Web-Update startet z.B. per sudo ein Script als root, welches den Code aktualisiert...)

Soll man das hier diskutieren oder ist es besser, ich mache ein Issue im GitHub zu diesem Thema?

Hi,

wir wollen i-doit auf AlmaLinux 9 testen und haben festgestellt, dass der idoit-install nur für RHEL 9 gemacht ist, und dass sowohl die Installer als auch die manuelle Anleitung eine ganze Reihe von Fehlern für EL Distros enthält.

Ich habe mal angefangen, das idoit-install für beliebige EL Distros zu verallgemeinern, aber nachdem ich die diversen Fehler in den weiteren Schritten gesehen habe, bin ich zögerlich, ob sich der Aufwand überhaupt lohnt bzw. ob daran überhaupt Interesse bestehen würde. Wenn ich die Doku sehe, befürchte ich, dass ich da ein Fass auf mache...

Darüber hinaus wäre es für uns auch wichtig, eine saubere Rechtetrennung schon bei der Installation zu etablieren, d.h. insbesondere nicht allen Scripte und Code von i-doit dem Benutzer apache mit Schreibrechten zu geben. Der Webserver sollte nie in der Lage sein, seine eigenen Scripte zu verändern. Das ist ein Grundprinzip der Rechtetrennung. (Wir wollen das auch nicht für die Updates, da sollte eigentlich der Code vom Admin als root aktualisiert werden und dann kann der Rest im Webserver laufen...) Dann passt das auch mit SeLinux und man muss nicht effektiv das SeLinux kaputt konfigurieren, damit es nicht in den Weg kommt.

Grüße.