SELinux

Security Enhanced Linux (SELinux) ist eine Erweiterung des Linux-Kernels, die hauptsächlich von Red Hat und (interessanterweise) der NSA weiterentwickelt wird. Es sorgt auf Basis von Labeln und Regeln (den „Access Vectors“), dass Prozesse nur auf die Ressourcen Zugriff erhalten, die sie unmittelbar benötigen. Man kann sich SELinux also grob als eine Art Applikations-Firewall vorstellen. Es können jederzeit eigene Regeln definiert werden.

SELinux kennt drei verschiedene Betriebs-Modi:

Enforcing

Im Standard aktiv. Die Regeln werden durch den Kernel angewendet. Regel-Anwendungen werden in /var/log/audit/audit.log protokolliert.

Permissive

Die Regeln werden durch den Kernel nicht angewendet, sie werden aber in /var/log/audit/audit.log protokolliert, als würden sie angewendet werden.

Disabled

SELinux ist komplett abgeschaltet.

Da SELinux ein Labeling-System ist, besitzt jeder Prozess, jede Datei, jedes Verzeichnis und jedes System-Objekt (Ports etc.) ein Label / den SELinux-Kontext. Die SELinux-Policies erlauben und definieren den Zugriff von gelabelten Prozessen auf gelabelte Objekte. Der Kernel sorgt für deren Einhaltung.

Die beiden wichtigsten Konzepte sind

1. Das Labeling (Dateien, Ports, Prozesse etc.)

2. Type Enforcement (also die Isolation von Prozessen auf Basis ihrer Labels).

Das korrekte Label-Format für einen Kontext ist user:role:type:level.

Um SELinux temporär für das ganze System abzuschalten, setenforce 0 verwenden. Doch Vorsicht: das System ist von da an ungeschützt. Um SELinux zur Laufzeit auf „enforcing“ zu setzen , setenforce 1 nutzen.

So setzt man SELinux dauerhaft auf den Enforcing Mode (was der Standard-Einstellung in RHEL entspricht). Anschliessend ist ein Reboot fällig:

/etc/sysconfig/selinux

SELINUX=enforcing

Hinweis

Es gibt nur sehr wenige Ausnahmen, in denen man SELinux gänzlich abschalten sollte. Sehr wenige. Wirklich. Wer trotzdem darüber nachdenkt, weil man den Aufwand der Policy-Konfiguration scheut, sollte vorher probieren, einzelne Server-Prozesse in den Permissive-Mode zu schicken.

Die umfangreichen Manpages zu SELinux installiert man mit

yum -y install selinux-policy-devel
mandb

SELinux kommt auf RHEL nativ zum Einsatz. Auf Ubuntu lässt es sich nachinstallieren (AppArmor dabei deaktivieren).

Links

• https://www.nsa.gov/Portals/70/images/resources/everyone/digital-media-center/publications/research-papers/configuring-selinux-policy-report.pdf

Funktionsweise

Das Labeling-System:

• Prozesse haben Label: Der Apache besitzt z.B. das Label httpd_t.

• Ports haben Label: Der Apache darf im SELinux-Standard auf den Ports 80, 81, 443, 488, 8008, 8009, 8443 und 9000 lauschen.

• Dateien und Verzeichnisse haben Label: /var/www/html besitzt das Label httpd_sys_content_t, oder httpd_sys_rw_content_t, wenn es beschreibbar sein darf. Dateien erhalten dafür erweiterte Attribute, die nur mit aktuellen Dateisystemen wie Ext3/Ext4/XFS gespeichert werden können.

• Der Kernel kontrolliert anhand einer Regel-Datenbank, ob diese Label zusammenspielen und was sie bewirken dürfen. Die SELinux-Datenbank, die diese Policies enthält, wird laufend durch die Installation von Software und Updates per Yum erweitert und gepflegt (in einer Minimal-Installation umfasst sie mindestens 6’000 Regeln, Tendenz steigend).

Ein Kontext-Label wie system_u:system_r:httpd_t:s0 besteht immer aus vier Komponenten:

• User Component: system_u. Der SELinux-Benutzer. User Components enden meist auf _u. Andere Beispiele: guest_u, root.

• Role Component: Rollenkonzept für Ressourcen. system_r beispielsweise für Prozesse, object_r für Dateien. Role Components enden meist auf _r. Andere Beispiele: staff_r.

• Type Component: httpd_t. das wichtigste Feld, da SELinux im Standard ein Type Enforcement System ist. Der Typ endet meist auf _t.

• Multi-Level Security (MLS) Component - oder kurz die „Sensitivity“: Identifiziert einen einzelnen Level oder einen Bereich. Steht in einer „targeted“-Policy immer auf s0 (Single Level).

SELinux würde zunächst jeden Zugriff eines Prozesses auf Systemressourcen jeglicher Art (Dateien, Verzeichnisse, Ports etc.) abweisen und nur selektiv anhand von Regeln Zugriffe erlauben - die so genannte „strict“-Policy. In der Praxis ist das nicht handhabbar, weswegen es mehrere Policies gibt:

• Minimum

• Multi-Level Security (MLS)-Enforcement: Erlaubt Prozessen Zugriff auf Daten anhand ihres Security Levels. Beispielsweise kann dann ein „Secret“-Prozess keine als „Top-Secret“ eingestuften Daten lesen.

• Multi-Category Security (MCS)-Enforcement: Schützt Prozesse voreinander (wie virtuelle Maschinen, OpenShift Gears, SELinux Sandboxes, Container usw.).

• Targeted (Single-Level Security - jeweils eine Policy pro Applikation): Die Standard-Policy in RHEL, die das Verhalten ausgewählter System-Prozesse kontrollierbar macht (zu finden unter /etc/selinux/targeted). In der „targeted“-Policy wird die Type-Komponente ausgewertet, nicht aber die Rollen- und Multi-Level-Komponente, weswegen man von einer „Type Enforcement Policy“ spricht. Alles andere läuft in der „unconfined“-Policy.

• Unconfined: Diese Programme werden nicht durch SELinux kontrolliert.

Mit sesearch lässt sich ein Blick in die Policy-Datenbank werfen oder herausfinden, wie Policies und Booleans technisch definiert sind:

yum -y install setools-console

sesearch --allow

# RHEL 7
sesearch --bool rsync_export_all_ro --allow --show_cond

# RHEL 8+, Fedora
sesearch --bool rsync_export_all_ro --allow

Der Admin kann mit dem Befehl semanage bequem Datei- und Port-Kontexte einsehen als auch eigene Regeln hinzufügen.

# up to RHEL 7
yum -y install policycoreutils-python

# RHEL 8+
dnf -y install policycoreutils-python-utils

semanage fcontext --list | grep http
semanage port --list | grep http

Welche Regeln werden auf das /var/www-Verzeichnis angewendet?

semanage fcontext --list | grep /var/www | sort

Tipp

Diese man-Pages erklären SELinux: man -k selinux

Dateien und Verzeichnisse

Der Apache darf auf die Verzeichnisse und Dateien /var/www/html und ~/public_html zugreifen, da sie den SELinux-Dateikontext httpd_sys_content_t tragen, nicht aber auf die Passwort-Datei /etc/shadow, da diese den Kontext shadow_t besitzt und keine Regel für Apache existiert, die den Zugriff darauf erlauben würde. Ein Eindringling, der den Apache kompromittiert hat, kann so nie an Systemdateien gelangen.

Gesetzte Datei-Labels ermittelt man immer mit dem Parameter -Z:

• ls -Z /etc/shadow

Dateien nehmen beim Verschieben ihren SELinux-Kontext mit, beim Kopieren erben sie den Kontext des Zielverzeichnisses. Verschobene Dateien müssen daher „umgelabelt“ werden, was man mit restorecon erledigt.

Die „Datenbank“, in der alle SELinux Datei-Kontexte gepflegt sind, findet man hier:

cat /etc/selinux/targeted/contexts/files/file_contexts

...
/root(/.*)?    system_u:object_r:admin_home_t:s0
...
/var/www(/.*)? system_u:object_r:httpd_sys_content_t:s0
...

Prozesse

Prozess-Labels ermittelt man immer mit dem Parameter -Z:

• id -Z

• ps auxZ | grep httpd

Prozess auf „permissive“ setzen

Beispiel logrotate: dieses läuft unter dem Kontext „logrotate_t“. Damit der Prozess auch bei Enforcing auf Dateien zugreifen kann (braucht man beispielsweise, wenn logrotate ein selbstgeschriebenes postscript ausführen soll, welches auf aussergewöhnliche Verzeichnisse zugreifen soll):

semanage permissive --add logrotate_t

Prozess wieder auf „enforcing“ setzen

semanage permissive --delete logrotate_t

SELinux-Booleans

Mit „Policy booleans“ lassen sich einfache SELinux-Sicherheitsvorgaben zur Laufzeit ein- bzw. ausschalten. Booleans sind eigentlich eine Art Shortcut für komplexere Policy-Module. Für fast jeden Prozess gibt es eine Reihe an Schaltern, beispielsweise erlaubt eine aktivierte Einstellung httpd_enable_cgi dem Apache, CGI-Skripte auszuführen. Möchte der Administrator CGI-Skripte unterbinden, setzt er diesen Wert einfach auf 0/false/off. Die meisten Booleans sind standardmässig deaktiviert.

Eine Liste der installierten Booleans (ist immer installationsabhängig) erhält man mit getsebool -a, gefiltert nach denen für Apache mit getsebool -a | grep http. Ausführlicher mit Beschreibung und Default-Werten geht es mit Hilfe von semanage boolean --list --locallist.

Um im obigen Beispiel CGI-Skripte zu deaktivieren, benutzt man setsebool. Der Parameter -P sorgt dafür, dass die Einstellung permanent gesetzt wird und somit einen Neustart überlebt.

setsebool -P httpd_enable_cgi off

Um den Schalter einfach auf seinen entgegengesetzten Wert umzulegen, kann man auch togglesebool httpd_enable_cgi verwenden.

SELinux Audit-Log

Wird einer Software der Zugriff auf eine Ressource untersagt, landet dies schwer lesbar in der /var/log/audit/audit.log, was im Fall eines Apache, der auf einen MariaDB-Server zugreifen wollte, so aussehen kann (und der Übersichtlichkeit halber optisch aufbereitet wurde):

type     = AVC
msg      = audit(1322708342.967:16804): avc: denied { name_connect } for pid = 2724
comm     = "httpd"
dest     = 3306
scontext = unconfined_u:system_r:httpd_t:s0
tcontext = system_u:object_r:mysqld_port_t:s0
tclass   = tcp_socket

Das Format einer Nachricht im SELinux-Log kurz erklärt (Auszug):

• type: AVC = „Access Vector Cache“ Message, Kernel Event, SYSCALL = System-Aufruf.

• msg: Enthält die Seriennummer der Nachricht. So erkennt man zusammenhängende Nachrichten.

• comm: Name des Executables.

• dest: Ziel, z.B. ein Port.

• scontext: Security-Kontext des Source-Objektes.

• tcontext: Security-Kontext des Target-Objektes.

Es gibt Tools, die einem beim Anschauen helfen oder sogar bis zu einer gewissen Grenze im Klartext erklären können, was seitens SELinux verboten wurde.

ausearch

Statt /var/log/audit/audit.log direkt anzuschauen:

ausearch --start recent --message avc --interpret

audit2why

Dazu packt man die ermittelten audit.log-Zeilen in eine separate Datei und füttert diese an audit2why, einem Tool aus den policycoreutils-python:

# RHEL 7
yum -y install policycoreutils-python
# RHEL 8+
dnf -y install policycoreutils-python-utils

ausearch --start recent --message avc > /tmp/myaudit.log
audit2why < /tmp/myaudit.log

sealert

Wird das nachfolgende Paket installiert und der Server neu gestartet, tauchen lesbare SELinux-Meldungen in /var/log/messages bzw. journalctl auf.

yum -y install setroubleshoot-server

sealert --lookupid 12fd8b04-0119-4077-a710-2d0e0ee5755e
#SELinux is preventing httpd from getattr access on the file /var/www/html/index.html.

Beispiel 1: Apache „Permission Denied“

Sobald SELinux im Enforcing-Mode läuft, wird der Webserver Probleme bekommen, Dateien aus /var/www/html auszuliefern, die aus anderen Verzeichnissen dorthin verschoben wurden. Der Grund liegt im falschen Dateikontext; SELinux erwartet, dass Dateien, die durch httpd aus /var/www ausgeliefert werden dürfen, den Kontext httpd_sys_content_t aufweisen.

Zur Übung erzeugt man eine index.html im /tmp-Ordner. Die Datei besitzt damit den Dateikontext unconfined_u:object_r:user_tmp_t:s0. Verschiebt man sie in das /var/www/html-Verzeichnis, bleibt der Kontext erhalten - SELinux hindert den Apache folgerichtig daran, die Datei bei einem Aufruf per HTTP auszuliefern, der Apache gibt brav eine „Forbidden“ (ich darf nicht)-Meldung aus.

Der Datei-Kontext für /var/www/.* ist wohldefiniert und in der SELinux-Datenbank in Form von regulären Ausdrücken hinterlegt. So ermittelt man den resultierenden SELinux Security Context für Pfade und Dateien:

matchpathcon /var/www/html

Stimmt der Kontext, kann man die verschobenen Dateien einfach auf den Wert aus der Datenbank setzen:

restorecon -r /var/www/html

Damit File-Kontexte passend gesetzt werden können, muss man manchmal wissen, wie Transitions definiert sind. Hierbei helfen:

# what does mysqld_t do?
sesearch --allow --source mysqld_t --class file --perm execute

# check the Transition rules
sesearch --type --source mysqld_t

Ein Eintrag wie type_transition mysqld_t chkpwd_exec_t : process chkpwd_t; bedeutet dabei: Falls MySQL etwas ausführt, das mit chkpwd_exec_t gelabled ist, erhält der entstehende Prozess das Label chkpwd_t.

Beispiel 2: Apache mit neuer DocumentRoot

Angenommen, die DocumentRoot eines virtuellen Apache-Hosts liegt unter /data. SELinux hindert Apache an der Auslieferung der Dokumente, da dort erzeugte Dateien den sehr allgemeinen „unconfined_u:object_r:default_t:s0“-Kontext besitzen, der nicht zum Apache passt.

Hier muss die SELinux File-Context Datenbank ergänzt werden. /data und alle enthaltenen Unterverzeichnisse sollen mit dem File-Kontext des Apache verknüpft werden:

semanage fcontext --add --type httpd_sys_content_t "/data(/.*)?"

Hinweis

restorecon folgt keinen SymLinks, man muss bei der Definition von File-Contexts mit semanage also mit echten Pfadangaben arbeiten.

Falls der Apache Schreibrechte auf ein Verzeichnis benötigt, verwendet man folgenden Kontext:

semanage fcontext --add --type httpd_sys_rw_content_t "/data(/.*)?"

Anschliessend „restauriert“ man den Datei-Kontext unter /data, sprich: man labelt sie anhand der aktualisierten SELinux-Datenbank um.

restorecon -Fvr /data

Die Manpage hilft bei der Syntax der Befehle:

man semanage-fcontext

Löschen eines Kontextes (Beispiel):

semanage fcontext --delete --type httpd_log_t "/data(/.*)?"

Beispiel 3: Apache darf kein Mail senden

Im folgenden Szenario soll ein PHP-Skript, welches ein Mail-Kommando absetzt, durch Apache ausgeführt werden. Das Skript ist durch root im /root-Ordner erzeugt und nach /var/www/html verschoben worden. Apache ist standardmässig über SELinux so konfiguriert, dass keine Mails versendet werden dürfen. Zusätzlich erwartet man hier Probleme wegen des falschen Datei-Kontextes.

Zunächst schafft man die Übungsvoraussetzungen, installiert Apache PHP, erzeugt das Skript und verschiebt es:

setenforce 1
yum -y install httpd php
systemctl restart httpd
firewall-cmd --add-service=http
setsebool -P httpd_can_sendmail off

cat >/root/test.php <<EOF
<?php
if (mail('root', 'subject', 'message')) {
    echo 'OK';
}
else {
    echo 'NOK';
}
?>
EOF
mv /root/test.php /var/www/html
chown apache:apache /var/www/html/test.php

Der Aufruf http://myserver/test.php wird durch den Apache mit einer leeren Seite und „Forbiden“ (403) quittiert. Wenn man mal so tut als wüsste man nicht warum, hilft folgende sequentielle Analyse:

tail /var/log/httpd/access_log
# "403" while accessing test.php
semanage permissive --add httpd_t
# Script works
semanage permissive --delete httpd_t
# Script won't work anymore
tail /var/log/httpd/error_log
# "Permission denied", so an OS related problem

Schnell noch die Datei-Berechtigungen prüfen: ein ls -l /var/www/html/test.php zeigt, dass der Besitzer der Datei und die Gruppe zum Account des Apache passen, und User und Group Leserechte auf die Datei besitzen.

Man weiss längst: SELinux ist das „Problem“. Ein Aufruf des Skripts auf der Kommandozeile mit php /var/www/html/test.php liefert ein „OK“, man muss den Fehler also im Apache-Kontext suchen. Ein Blick in die SELinux-Logs

tail /var/log/audit/audit.log

zeigt schon den falschen Target-Kontext tcontext=unconfined_u:object_r:admin_home_t:s0. Erfahrungsgemäss schaut man sich mit ls -Z /var/www/html/test.php den Datei-Kontext an und korrigiert:

restorecon /var/www/html/test.php

Ruft man die Seite erneut auf, erhält man jetzt immerhin ein „NOK“ - die Seite konnte aufgerufen, das Mail-Kommando jedoch nicht ausgeführt werden. SELinux hindert das im Apache-Kontext laufende PHP an der Mail-Kommunikation, worüber es im Audit-Log auch Auskunft gibt:

type     = AVC
msg      = audit(1410282955.098:649): avc:denied  { search } for  pid = 8840
comm     = "sendmail"
name     = "postfix"
dev      = "dm-1"
ino      = 9078592
scontext = system_u:system_r:httpd_t:s0
tcontext = system_u:object_r:postfix_etc_t:s0
tclass   = dir

type     = SYSCALL
msg      = audit(1410282955.098:649): arch=c000003e syscall=2 success=no exit=-13 a0=7f38ae492ea0 a1=0 a2=0 a3=0 items=0 ppid=8511 pid=8840 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295
comm     = "sendmail"
exe      = "/usr/sbin/sendmail.postfix"
subj     = system_u:system_r:httpd_t:s0 key=(null)

Die erste Zeile besagt, dass „sendmail“ über „postfix“ nicht ausgeführt werden durfte, Ursache („scontext“) war unser Apache-Prozess. Dafür gibt es einen SELinux-Boolean, wie man schnell herausfindet:

man httpd_selinux | grep mail

führt zu

setsebool -P httpd_can_sendmail on

Beispiel 4: Apache und entfernte MariaDB

Ein Python-Skript unter Apache möchte eine Verbindung zu einer entfernten MariaDB-Datenbank aufbauen, was verhindert wird. Die passende Zeile aus dem audit.log wurde in einer eigenen /tmp/myaudit.log abgelegt. Jetzt untersucht man, was zu tun ist:

ausearch --start recent --message avc > /tmp/myaudit.log
# type     = AVC
# msg      = audit(1322708342.967:16804): avc: denied { name_connect } for pid=2724
# comm     = "httpd"
# dest     = 3306
# scontext = unconfined_u:system_r:httpd_t:s0
# tcontext = system_u:object_r:mysqld_port_t:s0
# tclass   = tcp_socket

yum -y install policycoreutils-python
dnf -y install policycoreutils-python-utils

audit2why < /tmp/myaudit.log

Die Ausgabe sagt, was man zu tun hat:

One of the following booleans was set incorrectly.
Description:
Allow HTTPD scripts and modules to connect to the network using TCP.

Allow access by executing:
# setsebool -P httpd_can_network_connect on
Description:
Allow HTTPD scripts and modules to connect to databases over the network.

Allow access by executing:
# setsebool -P httpd_can_network_connect_db on

Da das Skript sich zu einem „well-known“ Standard-Datenbank-Port verbinden möchte, genügt:

setsebool -P httpd_can_network_connect_db on

Beispiel 5: Apache auf einem anderen Port lauschen lassen

Da der Apache nur auf bestimmten Ports hören darf, wird die Konfiguration eines nicht standardkonformen Ports SELinux auf den Plan rufen. So fügt man eine neue Regel für Port 8080 hinzu:

semanage port --add --type http_port_t --proto tcp 8080

Die Manpage hilft bei der Syntax des Befehls:

man semanage-port | grep semanage

Beispiel 6: Apache „permissive“ laufen lassen

Nur, wenn es unbedingt sein muss, und man SELinux dann doch nicht komplett abschalten möchte:

semanage permissive --add httpd_t

Beispiel 7: Eigenes SELinux Module Package bauen

Siehe https://access.redhat.com/articles/5494701.

yum -y install setools-console

Dann:

• Tool oder Service permissive laufen lassen:

  semanage permissive --add mysqld_t

  systemd-run --unit fake_mysqld.service /usr/local/bin/mysqld
• AVCs sammeln: ausearch --message AVC,USER_AVC --start recent.

  Beispiel: Es wird ein AVC Denial für den Source Context mysqld_t und den Target cifs_t gemeldet.

  type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=XXX comm="mysqld" path="/cifs-server/data/file.csv" dev="cifs" ino=XXX scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file permissive=0
• semanage permissive --delete mysqld_t
• Prüfen, ob es wirklich keine Rule für den gemeldeten Type gibt:

  RHEL 8+: sesearch --allow --source mysqld_t --target cifs_t --class file --perm getattr

  RHEL 7: sesearch --show_cond --allow --source mysqld_t --target cifs_t --class file --perm getattr

audit2allow --all ausführen, um die Type Enforcement Regel anzuzeigen, die den verweigerten Zugriff erlaubt. Beispiel:

#============= httpd_t ==============
allow httpd_t var_log_t:file open;

Ist der Inhalt ok, kann das Custom-Modul generiert werden (würde auch mit einer Text-Datei funktionieren, die obiges enthält):

audit2allow --all -M mymodulename

Modul aktivieren:

semodule --install mymodulename.pp

Beispiel 8: Eigene Module Packages verteilen

Siehe https://access.redhat.com/articles/5494701.

Wichtig: Es genügt, aus der .te-Datei die .pp-Datei einmalig zu compilieren und letztere auf weiteren Zielsystemen per semodule --install zu installieren. Die .pp-Datei muss allerdings für jede Plattform separat compiliert werden (also je eine .pp-Datei für RHEL 7, RHEL 8 usw.). Ein Anwendungsbeispiel findet sich auf https://github.com/Linuxfabrik/monitoring-plugins/blob/main/BUILD.rst#compile.

Troubleshooting

Fail to load SELinux policy. Freezing.

Wahrscheinlich ist das System falsch gelabelt. Kernel-Parameter selinux=0 beim Booten mitgeben, um SELinux abzuschalten. Anschliessend touch /.autorelabel && reboot ausführen, um das System komplett umlabeln zu lassen. Danach ist Geduld gefordert, wenn das System viele Dateien hostet.

Built on 2024-04-18