[CentOS-de] Kein Zugriff auf Webseite

[Rainer.Rose at HannIT.de]

Moin!

>> Am 08.09.2017 um 23:05 schrieb Andreas Meyer <a.meyer at nimmini.de>:
>Apache hat da einen 403 gemeldet. Es funktioniert jetzt.
> [...], weil auch die Rechte gestimmt haben und eine index.html vorhanden war.
> [...]
> Ich habe gesucht und auch gelesen, dass selinux schuld sein kann. [...]kenne es nicht.
>
>> Zeigt 'sealert -a /var/log/audit/audit.log' denn überhaupt SELinux Fehler?
>
># sealert -a /var/log/audit/audit.log
>bash: sealert: Kommando nicht gefunden.

Mir geht es ähnlich. Ich bin recht neu unter CentOS und hatte es mir vor Jahren mal angeguckt. Jetzt muss ich mich beruflich damit beschäftigen. Leider habe ich auch so meine Schwierigkeiten mit SElinux.
Grundsätzlich ist es so, dass reine Dateirechte mit SElinux erstmal nicht ausreichen. Die SElinux-Rechte bzw. ACLs müssen auch stimmen.
Es soll eine zusätzliche Sicherheitsschicht darstellen. Ich mach es mal kurz, so wie ich es verstanden habe. Theoretische könnte man unter Ausnutzung von Sicherheits und Konfig-Lücken, den Apache dazu bringen einen kleinen zusätzlichen Webserver mit nc (netcat) zum rennen zu bringen und sich dann auf dem System auszutoben.[1] Auch das Auslesen der /etc/passwd ist so ein beliebtes Szenario.
SElinux soll nun genau das verhindern. Ausbrechen außerhalb der konfigurierten Verzeichnisse und einfach mal so eben eine Port (für den nc) aufzumachen is' nich'.

Dafür gibt es weitere "Gefängnisse" für den Apache-Prozess.
Im Dateisystem gibt es erweiterte Dateirechte, die man sich z.B. mit -Z ,also
$ ls -lZ
angucken kann. Wichtig, auch z.B. tar muss man den SElinux-Kontext beim Sichern beibringen, sonst verschwindet die Info (  --selinux)

Sieht dann z.B. so aus

$ ls -lZ /var/www/
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html

Wie und wo man diese Labels (httpd_sys_content_t) konfiguriert werden, habe ich noch nicht rausgefunden und tue mich damit schwer, weil auch bei mir sealert nicht vorhanden scheint 

[root at localhorst] $ find / -name "*sealert*" -type f

ergibt kein Ergebnis.
Eine gute Anlaufstelle ist IMHO das centos-Wiki, was mir ein bisschen Einblick gewährt hat.


https://wiki.centos.org/HowTos/SELinux 

dort steht auch ein Beispiel, wie man den Document-Root außerhalb des Standards von /var/www/ konfigurieren kann.

Ich hab dann hier noch die Aufgabe als nicht privilegierter User einen mitgebrachen glassfish-Server zum Laufen zu bekommen. Das wird auch noch spannend. Vermutlich muss man da neue Labels definieren, aber verstanden habe ich es noch nicht (s.o.), aber das war ja nicht Thema des Threats.

[1] Besser erklärt : https://www.heise.de/ct/ausgabe/2015-4-SELinux-und-AppArmor-schuetzen-nach-dem-Einbruch-2521204.html die ersten beiden Artikel-Seiten

HTH.

Gruß,
Rainer