Deep Dive: SELinux auf einem K3s-Host – Type Enforcement, und die zwei Male, in denen es still nichts tat

🌐 Auch auf: English · Français · Español

Deep Dive aus der Reihe rund um die Ansible-Tour. Niveau: fortgeschrittene Linux-Administration. Die Tour erklärt die Rollen; die Deep Dives erklären die Technik darunter – wie sie funktioniert, warum sie hier ist, was dieses Setup genau damit macht, wie man sie im Alltag betreibt und was es sonst gegeben hätte.

SELinux ist die Schicht, die die meisten Administratoren zuerst abschalten und zuletzt verstehen. Schade, denn es ist auf diesen Servern die einzige Schicht, die auch dann noch hält, wenn ein Prozess schon übernommen ist – selbst einer, der als root läuft. Dieser Beitrag erklärt zuerst, wie SELinux entscheidet, mit den Details, die in der Praxis zählen: Typen, Übergänge, Kategorien und wie man eine Verweigerung liest. Danach geht es um den Blog und die beiden Nextcloud-Server: was eingeschränkt ist, wie, und die zwei Gelegenheiten, bei denen SELinux eingeschaltet war, auf enforcing stand und trotzdem nichts schützte – weil ein einziges Detail an anderer Stelle dafür sorgte, dass die richtigen Regeln nie griffen.

🧭 Wie SELinux entscheidet

Benutzerbestimmt und verpflichtend

Die klassischen Unix-Rechte sind benutzerbestimmt (discretionary): Wem die Datei gehört, der entscheidet, wer sie lesen darf, und root darf alles. SELinux setzt eine verpflichtende Schicht (mandatory) darüber. Bei jeder relevanten Operation – Datei öffnen, Socket verbinden, Signal schicken, Programm ausführen – fragt der Kernel eine zentrale Policy, und die Antwort hängt weder davon ab, wem die Datei gehört, noch davon, ob der Prozess root ist. Beide Prüfungen müssen Ja sagen. Ein Webserver, der als root läuft, kann /etc/shadow trotzdem nicht lesen, wenn die Policy seinem Typ das Lesen des Typs dieser Datei nicht erlaubt.

Labels: vier Felder, von denen eines fast die ganze Arbeit macht

Jeder Prozess und jedes Objekt – Datei, Verzeichnis, Socket, Port, selbst die Strukturen des Kernels – trägt einen Sicherheitskontext der Form user:role:type:level. Auf einem Server mit der targeted-Policy, die AlmaLinux mitbringt, spielen drei der vier Felder kaum eine Rolle: Der User ist fast immer system_u oder unconfined_u, die Rolle system_r oder object_r. Entschieden wird über den Typ. Bei einem Prozess heißt der Typ seine Domain.

$ ps -eZ | grep -E ' (mariadbd|redis-server|php-fpm)$'
system_u:system_r:mysqld_t:s0              ... mariadbd
system_u:system_r:redis_t:s0               ... redis-server
system_u:system_r:container_t:s0:c628,c864 ... php-fpm

$ ls -Zd /var/lib/mysql /var/lib/redis
unconfined_u:object_r:mysqld_db_t:s0       /var/lib/mysql
system_u:object_r:redis_var_lib_t:s0       /var/lib/redis

Die Labels von Dateien stehen als erweiterte Attribute (security.selinux) im Dateisystem. Woher das Label einer Datei kommt, ist die Quelle der meisten SELinux-Probleme, deshalb lohnen sich die drei Wege: Eine neue Datei erbt den Typ ihres Verzeichnisses; eine Type-Transition-Regel der Policy kann sagen „Dateien, die Domain X in einem Verzeichnis vom Typ Y anlegt, bekommen Typ Z“; und restorecon setzt Labels aus der File-Context-Datenbank – Regeln wie /var/lib/mysql(/.*)? → mysqld_db_t, die die Policy mitbringt und die semanage fcontext erweitert. Verschieben behält das Label, Kopieren vergibt ein neues. Der Klassiker: eine Konfigurationsdatei, aus dem Home-Verzeichnis nach /etc verschoben und danach für ihren Dienst unlesbar.

Type Enforcement

Die Policy ist im Kern eine große Menge von Erlaubnisregeln zwischen Typen: allow mysqld_t mysqld_db_t:file { read write open … }; – ein Prozess in der Domain mysqld_t darf Dateien vom Typ mysqld_db_t lesen und schreiben. Was nicht erlaubt ist, wird verweigert. Die targeted-Policy auf diesen Hosts umfasst weit über hunderttausend solcher Regeln, kompiliert zu einer Binärdatei, die der Kernel lädt; 439 Module ergeben das Ganze, von apache bis zabbix. Der Sinn des Namens „targeted“: Eingeschränkt sind nur Dienste mit eigenem Modul. Alles andere läuft in einer unbeschränkten Domain, der fast alles erlaubt ist – und genau dort, wie der zweite Fall unten zeigt, kann etwas unbemerkt durchrutschen.

Domain-Übergänge – und warum NoNewPrivileges sie stoppen kann

Ein Prozess bekommt seine Domain bei execve(). Die Regel type_transition init_t mysqld_exec_t:process mysqld_t sagt: Wenn etwas in init_t (systemd) eine Datei vom Typ mysqld_exec_t ausführt, läuft der neue Prozess in mysqld_t. Deshalb zählt das Label eines Programms genauso wie das Label der Daten: Ein mariadbd-Binary mit dem Label bin_t käme nie in seine Domain.

Es gibt ein feines Zusammenspiel mit einer systemd-Option, die sonst ein reiner Gewinn an Härtung ist. NoNewPrivileges=yes setzt das Kernel-Flag PR_SET_NO_NEW_PRIVS: Danach kann execve() nie mehr Rechte gewinnen – kein setuid, keine Datei-Capabilities. SELinux behandelt einen Domain-Übergang ebenfalls als mögliche Rechteänderung. Unter NNP erlaubt es einen Übergang nur, wenn die Ziel-Domain eine Teilmenge der Quelle ist (bounded) oder die Policy für dieses Paar ausdrücklich nnp_transition gewährt. Trifft beides nicht zu, wird der Übergang abgelehnt – und das Programm läuft in der Domain seines Elternprozesses weiter. Mehrere andere systemd-Sandbox-Optionen setzen NNP stillschweigend mit. Das sollte man sich merken; es ist der erste Fall unten.

MCS: das Level-Feld, das Container auseinanderhält

Das vierte Feld, das Level, lautet normalerweise s0. Mit Multi-Category Security kann es Kategorien tragen: s0:c628,c864. Ein Prozess darf auf ein Objekt nur zugreifen, wenn seine Kategorien die des Objekts dominieren: Ein Prozess mit c628,c864 kann eine Datei mit genau diesen Kategorien lesen oder eine ohne Kategorien (s0), aber nicht eine mit c53,c213. Container-Runtimes trennen damit Container, die sich alle einen Typ teilen: Jeder Pod bekommt sein eigenes zufälliges Paar. Alle 46 Container-Prozesse auf einem Nextcloud-Host laufen als container_t, und trotzdem kann Collabora (c53,c213) die Dateien des PHP-Containers (c628,c864) nicht anfassen.

Eine Folge übersieht man leicht: Ein Host-Verzeichnis, das in Pods eingebunden und mit container_file_t:s0 gelabelt ist – also ohne Kategorien –, ist für jeden Container erreichbar. MCS trennt die eigenen Dateisysteme der Container, nicht gemeinsame Volumes. Auf diesen Servern gehört jedes HostPath-Verzeichnis genau einer Anwendung, das ist also in Ordnung; auf einem Knoten mit mehreren Mandanten wäre es das nicht.

Eine Verweigerung lesen

Sagt die Policy Nein, schreibt der Kernel eine AVC-Meldung (Access Vector Cache) ins Audit-Log. Diese hier stammt von der Prüfung des Dateiintegritäts-Werkzeugs und enthält alles, was man zum Verstehen braucht:

type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=... comm="aide"
  name="/" dev="vda2" scontext=system_u:system_r:aide_t:s0
  tcontext=system_u:object_r:dosfs_t:s0 tclass=filesystem permissive=0

Als Satz gelesen: Der Prozess aide in der Domain aide_t wollte getattr auf ein Objekt der Klasse filesystem vom Typ dosfs_t – die vfat-EFI-Partition – und wurde abgewiesen (permissive=0). ausearch -m AVC -ts today findet solche Meldungen, audit2why erklärt, welche Regel fehlt oder welcher Boolean es erlauben würde. audit2allow -M würde ein Modul schreiben, das genau das Verweigerte erlaubt – und das ist der gefährlichste Befehl der SELinux-Administration, weil er jedes Symptom in eine Erlaubnis verwandelt, ohne zu fragen, ob der Zugriff legitim war.

🛡️ Warum es überall an ist

Alle drei Server laufen mit der targeted-Policy im enforcing-Modus, und jede Rolle setzt das voraus. Der Grund ist ein Bedrohungsmodell, kein Haken auf einer Liste. Der realistische Angriff auf einen Blog ist ein verwundbares WordPress-Plugin, auf Nextcloud ein präpariertes Dokument, das die Office-Suite ausnutzt. In beiden Fällen hat der Angreifer danach Codeausführung in einem PHP- oder Collabora-Prozess. Alles Weitere – die Datenbankdateien direkt lesen, SSH-Schlüssel stehlen, ein Programm auf dem Host ablegen, die andere Anwendung angreifen – hängt davon ab, was dieser Prozess darf. Unix-Rechte helfen dabei wenig; im Container ist der Prozess oft ohnehin root. SELinux ist die Schicht, die unabhängig von Benutzer-IDs „Nein“ sagt.

• Ein PHP-FPM-Worker in container_t darf nur container_file_t schreiben – sein eigenes Volume. Die Policy enthält keine Regel, die container_t das Lesen von shadow_t erlaubt; /etc/shadow bleibt also selbst für einen root-Prozess unerreichbar, der aus seinem Mount-Namespace ausgebrochen ist.
• Die MariaDB auf dem Host in mysqld_t darf ihr eigenes mysqld_db_t lesen und schreiben, ihren Port belegen und wenig mehr. Ein kompromittierter Datenbankserver kann die Nextcloud-Nutzerdaten in /data nicht lesen, die container_file_t sind.
• Redis in redis_t genauso: sein eigenes redis_var_lib_t, sein Port, sein Socket.
• Kernelmodule, rohe Geräte, ptrace auf andere Domains: all diesen standardmäßig verweigert.

Die Kosten sind gering, sobald die Labels stimmen. Fast jedes SELinux-Problem auf diesen Hosts war bisher ein fehlendes oder falsches Label, keine fehlende Regel – und die Policy für Datenbanken, Redis und Container kommt fertig mit der Distribution und container-selinux.

🔧 Was dieses Repository macht

common_selinux: enforcing und die richtigen Labels

Die Rolle setzt den Modus auf enforcing mit der targeted-Policy und labelt die Host-Verzeichnisse, die die Pods einbinden. Welche das sind, hängt vom Stack ab: Das Playbook setzt die Variable stack, und ein Dictionary wählt das Profil – Web-Root und Datenbankverzeichnis beim Blog, Web-Root und Nutzerdaten bei Nextcloud. Für jedes Verzeichnis legt sie eine dauerhafte File-Context-Regel an und wendet sie an:

semanage fcontext -a -t container_file_t "/srv/wordpress-www(/.*)?"
restorecon -Rv /srv/wordpress-www

Die Regel liegt im Policy-Speicher und übersteht damit auch ein vollständiges Neu-Labeln; restorecon wendet sie auf das an, was schon da ist. Die Rolle liest zuerst die lokalen Regeln (semanage fcontext -l -C) und ergänzt nur, was fehlt – neuere semanage-Versionen scheitern an einer vorhandenen Regel nicht mehr, sondern schreiben eine Meldung nach stdout und beenden sich mit 0, was die Aufgabe einmal bei jedem Lauf „changed“ melden ließ.

Fall 1: eine Datenbank, auf enforcing – und unbeschränkt

Im September hat ein systemd-Drop-in die MariaDB auf den Nextcloud-Servern gehärtet: keine Capabilities, schreibgeschütztes Dateisystem bis auf das Datenverzeichnis, privates /tmp, ein Systemaufruf-Filter – und, ausdrücklich wie stillschweigend, NoNewPrivileges. MariaDB startete, Nextcloud lief, das Drop-in sah nach einer klaren Verbesserung aus. Fünf Wochen später zeigte ein Blick auf die laufenden Prozesse dies:

$ ps -eZ | grep mariadbd
system_u:system_r:initrc_t:s0   ... mariadbd

initrc_t statt mysqld_t. Die Unit der Distribution startet mariadbd nicht direkt, sondern über /bin/sh -c, um vorher ein Galera-Wiederherstellungsskript auszuführen. Die Shell läuft in initrc_t; wenn sie mariadbd ausführt, müsste der Übergang nach mysqld_t passieren – und unter NNP erlaubt die Policy ihn von initrc_t aus nicht. Das Audit-Log hat es bei jedem Start gesagt, in einer Zeile, die niemand gelesen hat: avc: denied { nnp_transition } … scontext=…initrc_t… tcontext=…mysqld_t… tclass=process2. Die Datenbank lief in der Domain der Shell weiter, die viel weniger eingeschränkt ist. Vom 11. September bis zum 16. Oktober war die MariaDB auf dem Host praktisch gar nicht durch SELinux beschränkt.

Die Lösung ist eine Zeile im Drop-in: das Programm direkt starten, ohne die Shell (Galera wird hier nicht genutzt, das Hilfsskript hat also nichts zu tun):

ExecStart=
ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER

Direkt von systemd ausgeführt, ist der Übergang aus init_t erlaubt, und ps -eZ zeigt wieder mysqld_t. Getestet wurde das vorher mit systemd-run und denselben Eigenschaften, die Änderung musste also nie an der Produktionsdatenbank ausprobiert werden.

Fall 2: Pods, die nie als container_t liefen

Der zweite Fall ist größer. SELinux stand auf allen drei Servern auf enforcing, die Host-Verzeichnisse trugen container_file_t, container-selinux war installiert – und am 19. Oktober, während diese Reihe entstand, zeigte ps -eZ, dass kein einziger Pod als container_t lief. Auf dem Blog waren sie spc_t („super privileged container“, praktisch unbeschränkt), auf den Nextcloud-Servern unconfined_service_t.

Zwei Dinge fehlten. K3s startet sein eingebettetes containerd nur dann mit SELinux-Unterstützung, wenn in seiner Konfiguration selinux: true steht; sonst ist enable_selinux bei containerd false, und es fragt die Policy nie nach einem Container-Label. Und K3s braucht sein eigenes Policy-Paket, k3s-selinux, das das Programm als container_runtime_exec_t labelt, damit es als container_runtime_t läuft. Auf dem Blog hatte das Installationsskript dieses Paket einmal hinzugefügt; auf den Nextcloud-Servern war das Programm schlicht bin_t, systemd startete es also als unconfined_service_t, und jedes Kind erbte das. Das ganze sorgfältige Labeln der Volumes war Vorbereitung für eine Prüfung, die nie stattfand.

common_k3s macht jetzt vier Dinge:

• fügt Ranchers signiertes Paket-Repository hinzu und installiert k3s-selinux,
• setzt selinux: true in /etc/rancher/k3s/config.yaml,
• führt nach jedem Download des Programms restorecon -v /usr/local/bin/k3s aus – get_url ersetzt die Datei über eine temporäre Datei im selben Verzeichnis, die dem neuen Programm das bin_t des Verzeichnisses gibt und die Policy beim nächsten Update stillschweigend wieder aushebeln würde,
• und erzeugt alle Workloads einmal neu, solange noch kein einziger Pause-Container als container_t läuft. Pods behalten die Domain, mit der sie gestartet wurden; eine Konfigurationsänderung allein schränkt nichts ein, was schon läuft.

Danach das Bild auf einem Nextcloud-Server: 46 Prozesse in container_t, jeder Pod mit eigenem Kategorien-Paar, nur privilegierte Pods in spc_t, und keine einzige AVC – weder von Nextcloud noch von Collabora mit seinen Mount-Namespaces noch von notify_push. Collabora war die Komponente mit dem meisten Ärgerpotenzial, weil sie für jedes Dokument ein Gefängnis aus Bind-Mounts baut; container_t erlaubt die Mount-Namespace-Operationen, die sie braucht.

Fall 3, klein: eine Regel für AIDE

Das Integritätswerkzeug AIDE läuft als aide_t und geht das ganze Dateisystem durch. Die EFI-Partition ist vfat (dosfs_t), und die Policy lässt aide_t nicht hineinschauen. Den Ausschluss von /boot/efi aus der Prüfung hielt AIDE davon ab, die Dateien zu lesen, aber nicht davon, statfs() auf den Einhängepunkt aufzurufen – 13 Verweigerungen pro Lauf, jede Nacht. Die sauberste Lösung ist ein lokales Modul mit genau einer Regel, auf dem Host gebaut und nur bei geänderter Quelle geladen:

module aide_dosfs 1.0;
require { type aide_t; type dosfs_t; class filesystem getattr; }
allow aide_t dosfs_t:filesystem getattr;

checkmodule -M -m -o aide_dosfs.mod aide_dosfs.te
semodule_package -o aide_dosfs.pp -m aide_dosfs.mod
semodule -i aide_dosfs.pp

Das ist das Gegenbeispiel zu audit2allow: Die Regel wurde von Hand geschrieben, nachdem entschieden war, dass das Lesen von Dateisystem-Metadaten legitim ist und nichts weiter gebraucht wird. Seitdem melden die drei Server gar keine AVC mehr – was auch die Voraussetzung ist, um die nächste echte zu bemerken.

Der Monitoring-Stack: eigene Domains, noch im Lernmodus

Nachtrag 20.10.2026: Die Lernphase auf dem Blog endete nach einem Tag, einschließlich eines Neustarts. 82.703 protokollierte Verweigerungen ließen sich auf 203 verschiedene Zugriffe zurückführen – die eigenen Daten der Dienste, /proc und /sys, ihre Ports, DNS, Mail, Grafanas Plugin-Binaries. Daraus wurden geprüfte Erlaubnis-Regeln, überwiegend Makros der Referenz-Policy; audit2allow -R lieferte nur den Entwurf. Eine Überraschung unterwegs: Ein Dateikontext für /run/grafana traf nie, weil die Policy /run-Pfade als /var/run nachschlägt. Nach einer Prüfung mit audit2why gegen alle gesammelten Verweigerungen und Neustarts aller drei Dienste – null neue AVCs – setzt der Blog seit dem 20. Oktober durch. Die Nextcloud-Server lernen noch ein paar Tage länger, weil mysqld_exporter nur dort läuft. Ein Nebeneffekt, den man kennen sollte: Die Flut der Permissive-Verweigerungen hatte audit.log alle zwei Stunden rotieren lassen.

Bis zum 19. Oktober liefen achtzehn Prozesse auf einem Nextcloud-Server noch als unconfined_service_t: Prometheus, die Exporter, Grafana mit seinen Plugins, Monit. Sie sind als einzelne Programme in /usr/local/bin (bin_t) oder aus einem Hersteller-Repository installiert, und die targeted-Policy hat kein Modul für sie. Seit diesem Tag haben sie eigene Domains – kleine lokale Module homelab_prometheus, homelab_node_exporter, homelab_mysqld_exporter und homelab_grafana, gebaut mit den Standard-Makros der Policy aus selinux-policy-devel, mit Typen für ihre Daten und Logs. Ein Detail hätte Fall 1 fast wiederholt: Die Units laufen mit NoNewPrivileges, also braucht jedes Modul zusätzlich init_nnp_daemon_domain(); ohne das wurde der Übergang von systemd abgelehnt, Grafana blieb in init_t, konnte seine eigene Datenbank nicht lesen und war auf dem Blog fünf Minuten weg. Die neuen Domains starten im Permissive-Modus: Es sind echte Domains, aber Verweigerungen werden nur protokolliert (permissive=1). Nach einigen Tagen normalen Betriebs werden aus den protokollierten Zugriffen geprüfte, von Hand geschriebene Erlaubnisregeln, und die Domains schalten auf enforcing. Monit bekommt bewusst keine Domain – es führt als root beliebige Prüfungen aus und startet Dienste neu –, dafür eine systemd-Sandbox, die seine Bewertung von 9.6 auf 7.1 gesenkt hat.

🧰 Administration im Alltag

Ein paar Gewohnheiten, die sich bewährt haben:

• Nach jeder Änderung an einer Service-Unit die Domain prüfen, nicht nur den Status. Ein Dienst, der „active (running)“ in der falschen Domain ist, sieht völlig gesund aus.
• Jede AVC als Befund behandeln. Auf einem ruhigen System sind sie selten genug, um jede zu lesen; sobald ein Grundrauschen bekannter Verweigerungen hingenommen wird, geht die wichtige darin unter.
• Neues Host-Verzeichnis für einen Pod? Ins Profil des Stacks in common_selinux eintragen, nie von Hand labeln. Das Backup-Verzeichnis des Update-Jobs auf dem Blog fehlte bis zum 19. Oktober im Profil; es funktionierte nur, weil die Pods noch nicht eingeschränkt waren.
• Der Permissive-Modus für eine einzelne Domain (semanage permissive -a <domain>) ist ein Werkzeug zur Fehlersuche für Minuten, keine Lösung. setenforce 0 auf einem Produktivsystem ist überhaupt keine Option.
• Nach einem Policy-Update listet semodule -l die lokalen Module weiter; kompiliert ein Modul gegen eine neue Policy nicht mehr, scheitert semodule -i laut im Playbook-Lauf, nicht still zur Laufzeit.

🔭 Was als Nächstes kommt

• Alarme bei neuen AVCs über Loki, damit die nächste stille Verweigerung – wie das nnp_transition, das fünf Wochen lang bei jedem Start von MariaDB im Log stand – schon beim ersten Auftreten eine Mail auslöst.
• Die Monitoring-Domains von permissive auf enforcing umstellen, sobald die protokollierten Zugriffe geprüft sind – geplant zum Ende der ersten Woche.
• Eigene Policies pro Workload mit udica, das aus den Mounts und Ports eines Containers eine Policy erzeugt – enger als das allgemeine container_t.
• Eine Prüfung in der Abschlusskontrolle des Playbooks, dass jeder Anwendungs-Pod als container_t läuft. Fall 2 hat Monate gedauert, weil nie jemand gefragt hat.

⚖️ Alternativen – und warum SELinux

SELinux passt, weil es schon da ist: AlmaLinux bringt eine ausgereifte targeted-Policy mit, container-selinux ist in containerd integriert, K3s hat ein eigenes Policy-Paket, und von Administratoren der RHEL-Familie wird erwartet, dass sie es kennen. Seine eigentlichen Kosten sind nicht die Komplexität, sondern die Stille – wie die beiden Fälle zeigen, kann es eingeschaltet sein und nichts tun, ohne dass es jemand merkt. Die Antwort darauf ist nicht, es abzuschalten, sondern zu prüfen, was es tatsächlich tut.