In diesem Blogpost geht es nicht um die Funktionsweise oder den Sinn von SELinux, sondern darum, was bei Problemen mit SELinux gemacht werden soll/kann.
SELinux ist Bestandteil von RHEL-Basierten Systemen wie Fedora oder CentOS. Deshalb trifft man hier auch immer wieder auf die Empfehlung, SELinux zu deaktivieren. Meiner Meinung nach müsste das in 99% der Fällen aber nicht sein. Was sollte beachtet werden, wenn man mit SELinux Probleme hat?
SELinux Alert Browser
Verwendet man den Gnome-Desktop, kann es vorkommen, dass der SELinux Alert Browser aufpopt oder SELinux Fehlermeldungen angezeigt werden. Keine Panik - die Lösung wird hier meistens schon mit Vorgeschlagen. Hier ein Beispiel so einer Meldung:
SELinux is preventing gsf-office-thum from 'map' accesses on the file /tmp/gnome-desktop-file-to-thumbnail.xlsx.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that gsf-office-thum should be allowed map access on the gnome-desktop-file-to-thumbnail.xlsx file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:
# ausearch -c 'gsf-office-thum' --raw | audit2allow -M my-gsfofficethum
# semodule -X 300 -i my-gsfofficethum.pp
Wenn man sich diese Meldung ansieht, Fallen zwei Punkte auf:
Zuerst sollte man auf bugzilla nachschauen, ob das Problem schon bekannt ist. Wenn Ja, wird vielleicht schon ein Bugfix in Aussicht gestellt. Wenn Nein, dann einfach auf Bugzilla anmelden und den Bug melden.
Die zweite Möglichkeit ist, eine eigene Policy zu erstellen. Dazu muss man dann nur - als root - die Befehle ausearch und semodule mit den passenden Optionen ausführen. Welche genau das sind, ist auch wieder aus der Meldung ersichtlich. Hier das Beispiel aus obiger Meldung:
ausearch -c 'gsf-office-thum' --raw | audit2allow -M my-gsfofficethum
semodule -X 300 -i my-gsfofficethum.pp
Wichtig: die #-Zeichen dürfen nicht mit ausgeführt werden.
httpd
Als weiteres Beispiel möchte ich httpd anführen. Hier kommt es immer wieder zu Zugriffs-Fehlern obwohl scheinbar alles korrekt konfiguriert ist. Mit
setenforce 0
kann man SELinux temporär deaktivieren. Wenn nun alles so funktioniert wie es sollte, aktiviert man SELinux mit
setenforce 1
wieder (ein Reboot bewirkt dasselbe). Nun sollte man als erstes die Lables auf den Verzeichnissen und Dateien prüfen. Dies funktioniert mit dem ls-Befehl.
ls -lZ
im /var/www ergibt z.b. folgende Ausgabe.
drwxr-xr-x. 2 root root system_u:object_r:httpd_sys_script_exec_t:s0 6 Oct 25 14:35 cgi-bin
drwxr-xr-x. 2 root root system_u:object_r:httpd_sys_content_t:s0 6 Oct 25 14:35 html
Wenn eine Datei oder ein Verzeichnis nach /var/www verschoben - nicht kopiert - wurde, hat diese dann falschen SELinux-Kontext.
drwxr-xr-x. 2 root root unconfined_u:object_r:var_t:s0 6 Feb 4 22:30 html2
Hat man so ein Verzeichnis oder so eine Datei gefunden kann das einfach korrigiert werden. Dazu muss das Paket policycoreutils-python-utils mit allen Abhängigkeiten installiert sein. Dann kann mit semanage und restorecon der SELinux-Kontext wieder korrekt gesetzt werden.
semanage fcontext -a -t http_sys_content_t "/var/www/html2(/.*)?"
restorecon -Rv /var/www/html2
drwxr-xr-x. 2 root root unconfined_u:object_r:httpd_sys_content_t:s0 24 Feb 4 22:33 html2
Das Kontext muss je nach Verwendung angepasst werden. Z.b. wird für ein Upload-Verzeichnis der Kontext httpd_sys_rw_content_t benötigt. Das würde jedoch den Inhalt dieser Kurzanleitung sprengen. Wenn hier Fehler auftauchen, am besten mit einer Suchmaschine nach SELinux und dem gewünschten Anwendungszweck suchen.
Schluss
Wenn man sich etwas mit SELinux befasst, anstelle es zu deaktivieren, bekommt man schnell einen Überblick darüber wie es funktioniert.