Hallo!
Ich bekomme keinen Zugriff auf eine Seite des vServers, den ich heute installiert habe.
Der Apache kann alle files lesen und eine index.html ist auch da, aber ich bekomme einfach
Forbidden
You don't have permission to access / on this server.
Hat jemand Rat? Auch selinux habe ich schon auf permissive gesetzt und werde es gleich abschalten.
Grüße
Andreas
Am 08.09.2017 um 23:05 schrieb Andreas Meyer a.meyer@nimmini.de:
Ich bekomme keinen Zugriff auf eine Seite des vServers, den ich heute installiert habe.
Und was steht in den error logs des Servers dazu?
Auch selinux habe ich schon auf permissive gesetzt und werde es gleich abschalten.
Warum? Gibt es damit Probleme oder spekulierst Du nur?
Zeigt 'sealert -a /var/log/audit/audit.log' denn überhaupt SELinux Fehler?
Hallo!
Kai Bojens kb@kbojens.de schrieb am 09.09.17 um 00:59:54 Uhr:
Am 08.09.2017 um 23:05 schrieb Andreas Meyer a.meyer@nimmini.de:
Ich bekomme keinen Zugriff auf eine Seite des vServers, den ich heute installiert habe.
Und was steht in den error logs des Servers dazu?
Apache hat da einen 403 gemeldet. Es funktioniert jetzt. Ich arbeite schon viele Jahre mit dem Apache, aber das was merkwürdig, weil auch die Rechte gestimmt haben und eine index.html vorhanden war.
Auch selinux habe ich schon auf permissive gesetzt und werde es gleich abschalten.
Warum? Gibt es damit Probleme oder spekulierst Du nur?
Ich habe gesucht und auch gelesen, dass selinux schuld sein kann. Habe es dann abgeschaltet. Das war das erste mal, dass ich mit selinux jemals konfrontiert wurde, 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.
Grüße
Andreas
Moin!
Am 08.09.2017 um 23:05 schrieb Andreas Meyer a.meyer@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@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-d... die ersten beiden Artikel-Seiten
HTH.
Gruß, Rainer
Am 12.09.2017 um 10:55 schrieb Rainer.Rose@HannIT.de:
Moin!
Am 08.09.2017 um 23:05 schrieb Andreas Meyer a.meyer@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.
Wenn man Probleme mit einem Programm hat, die vermutlich von SELinux verursacht werden, macht es Sinn SELinux zuerst auf 'Permissive' zu setzen. Damit werden die Regeln nicht angewendet, aber die Fehlermeldungen ins Log geschrieben.
root:~# setenforce 0
Danach kann mit 'audit2allow' aus dem Paket 'policycoreutils-python' das Log ausgewertet werden. Das zeigt einem schnell ein Problem auf, und es kann sogar Lösungen vorschlagen.
root:~# audit2allow -a -w
Manchmal muss man einfach nur einen Schalter umlegen:
root:~# setsebool httpd_can_network_connect=1 root:~# setsebool -P httpd_can_network_connect=1
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
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
Einen bestimmten Kontext für eine Datei oder ein Verzeichnis setzen:
root:~# chcon -t httpd_sys_content_t /var/www/html
Den Kontext eines Verzeichnisses und der Unterverzeichnisse wieder auf die Standardeinstellung zurücksetzen:
root:~# restorecon -vR /var/www/html
Man kann mit 'semanage' auch selbst Standardeinstellungen für ein Verzeichnis definieren. Damit bekommen neue Dateien automatisch den richtigen Kontext:
root:~# semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?'
-
Alex JOST -
Andreas Meyer -
Kai Bojens -
Rainer.Rose＠HannIT.de