Diagnostiquer les erreurs SELinux et autoriser de manière ciblée : du mode « permissive » aux Policy-Module

Lorsque un service signale „Permission denied“, le diagnostic des erreurs SELinux est une étape centrale : le système applique Mandatory Access Control (MAC), qui tranche au-delà des droits Unix classiques. Dans ce guide pratique, vous apprendrez comment diagnostiquer les erreurs SELinux, évaluer les AVC‑Denials, utiliser permissive de façon contrôlée, corriger les labels, ports et booleans et — seulement si nécessaire — créer de petits modules de policy. Public cible : administrateurs, ingénieurs système, opérateurs et pRESTataires techniques. Axes : procédures d’exploitation sécurisées, pièges Docker/Podman, séquences de vérification et stratégies de repli.

Kurz: Was SELinux macht und wie Denials erscheinen

SELinux ist eine Mandatory Access Control (MAC). Im Unterschied zur gewöhnlichen Dateirechteverwaltung (Discretionary Access Control, DAC) entscheidet SELinux anhand von Sicherheitskontexten (z. B. user:role:type:level), welche Domain (ein Prozesskontext, z. B. httpd_t oder container_t) welche Aktionen auf ein Objekt (Datei, Socket, port) ausführen darf. Ein verweigerter Zugriff wird als AVC Denial (Access Vector Cache) protokolliert und ist die primäre Diagnosequelle.

Systematische Prüfsequenz: so arbeiten Sie zielgerichtet

Arbeiten Sie nach einer festen Abfolge, um unnötige Änderungen zu vermeiden und die Blast Radius zu reduzieren. Reihenfolge: Status → Reproduzieren → Log sammeln → Kontextanalyse → Behebungsstrategie (Label/Port/Boolean → permissive für Sammlung → Policy‑Modul) → Test → Rückrollen.

Status prüfen und Logs sichern

# Modus und Policy
sestatus
getenforce

# Audit-Log (RHEL/Fedora) ansehen
sudo tail -n 200 /var/log/audit/audit.log

# Kurz-Report über AVCs
sudo aureport --avc --summary

Bevor Sie Änderungen vornehmen: Kopieren Sie relevante Logabschnitte in Ihr Incident-Ticket. Das erleichtert Review, Test und Rollback.

Denial reproduzieren und zeitlich eingrenzen

# AVC-Einträge seit Reproduktionszeitpunkt
sudo ausearch -m AVC,USER_AVC -ts recent

# AVC-Einträge in Datei schreiben
sudo ausearch -m AVC -ts 2026-07-27 10:00:00 > /tmp/avc.log

Wichtig: Führen Sie den fehlerhaften Ablauf im möglichst isolierten Testfenster aus, damit die gesammelten AVCs verständlich bleiben.

AVC-Log: Beispiel und Feldauslegung

# Beispiel eines AVC-Eintrags (gekürzt)
type=AVC msg=audit(1627392000.123:456): avc:  denied  { write } for  pid=2345 comm="httpd" name="uploads" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

Wichtigste Felder: scontext (Quellkontext = Prozessdomäne), tcontext (Zielkontext = Dateityp), tclass (Objektklasse, z. B. file, tcp_socket) und die Aktion (z. B. write). Wenn tcontext nicht dem erwartetem Typ entspricht (z. B. usr_t statt httpd_sys_rw_content_t), dann schlägt SELinux Alarm — selbst wenn Unix-Rechte korrekt sind.

audit2why als erste Interpretation

# Erklärung der Gründe
sudo ausearch -m AVC -ts recent | sudo audit2why

audit2why ordnet Denials zu Policy-Regeln und gibt Hinweise (z. B. welcher Boolean helfen könnte). Nutzen Sie die Ausgabe als Hinweisgeber, nicht als automatischen Fix-Plan.

Labels korrigieren: chcon vs. semanage fcontext & RESTorecon

chcon ändert den Kontext eines Objekts sofort, ist aber nicht persistent: Ein relabel (bei RESTore oder systemweiter Relabel) überschreibt es. semanage fcontext hinterlegt eine dauerhafte Regel in der SELinux-Konfigurationsdatenbank; RESTorecon wendet diese Regel auf Dateien an.

# Schnell: prüfen
ls -lZ /var/www/html/uploads

# Persistente Zuordnung erstellen
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
sudo RESTorecon -Rv /var/www/html/uploads

# Nur simuliert anzeigen, was verändert würde
sudo RESTorecon -Rvn /var/www/html/uploads

Relabel bei Systemmigration oder RESTore

Nach einem RESTore von Backups oder einer Migration müssen SELinux-Kontexte oft neu gesetzt werden. Für eine komplette, geplante Relabel-Aktion verwenden Sie:

# Vollständiges Relabel beim nächsten Boot (vorsichtig einsetzen)
sudo touch /.autorelabel
sudo reboot

Alternativ: gezielte RESTorecon-Aufrufe auf betroffenen Pfaden. Bei großen Dateibeständen planen Sie Zeitfenster und prüfen I/O‑Last.

Ports, Booleans und Netzwerkzugriffe

SELinux regelt auch Portzuordnungen und vordefinierte Verhaltensoptionen (Booleans). Wenn ein Dienst an einem Nicht‑Standardport läuft oder Netzwerkzugriffe benötigt, prüfen Sie Ports und Booleans vor einem Policy‑Modul.

# Port-Typen listen und Port hinzufuegen
sudo semanage port -l | grep http_port_t || true
sudo semanage port -a -t http_port_t -p tcp 8081

# Boolean anzeigen und permanent setzen
getsebool -a | grep '^httpd_'
sudo setsebool -P httpd_can_network_connect on

Booleans sind policy‑definierte Schalter. Verwenden Sie -P, um die Einstellung persistent zu machen (über Reboots hinweg).

Docker & Podman: Volumes, :Z/:z und typische Betriebsfallen

Container-Prozesse laufen in speziellen SELinux-Domains (z. B. container_t). Bei gemounteten Host-Volumes muss der Hostpfad passend gelabelt werden, sonst bleiben Zugriffe geblockt, obwohl Unix-Rechte korrekt sind. Engines bieten praktische Relabel-Marken.

:Z vs :z — praktische Bedeutung

• :Z erstellt ein privates Label für diesen Container (sicherer für einzelne Container).
• :z erlaubt ein geteiltes Label für mehrere Container (geeignet für Shared-Data, aber weniger RESTriktiv).

# Docker: Hostpfad für Container relabeln
docker run --rm -v /srv/appdata:/var/lib/app:Z myimage

# Podman hat analoges Verhalten
podman run --rm -v /srv/appdata:/var/lib/app:Z myimage

Wichtig: Relabels verändern Host-Label. Informieren Sie Backup-Jobs, Monitoring-Agents und Hostprozesse, da diese gegebenenfalls andere Erwartungen an SELinux-Kontexte haben.

Container und NFS

Bei NFS ist SELinux besonders sensibel: NFS-Server übergeben nicht immer SELinux-Kontexte. In solchen Fällen sind spezielle Booleans, NFS-Server-Einstellungen oder alternative Storage-Strategien zu prüfen. Planen Sie Container‑Workloads mit NFS‑Zugriff frühzeitig, sonst entstehen langfristige Policy‑Ausnahmen.

Policy‑Module: kontrolliert erstellen, reviewen und deployen

Erstellen Sie Module nur, wenn Labels, Ports und Booleans das Problem nicht lösen. Module sind nachhaltig und sollten wie jede Konfigurationsänderung versioniert, reviewed und getestet werden.

Empfohlener Ablauf für Module

1. Domain temporär permissive schalten (nur für Sammlung).
2. Relevanten Workflow durchführen und AVCs sammeln.
3. audit2allow verwenden, .te prüfen und manuell einschränken.
4. Modul testen in Staging, semodule -i in produktiver Rollout-Phase mit Change-Window.
5. Rollback testen (semodule -r) und Dokumentation anlegen.

# Beispiel: Modul erzeugen und installieren
sudo semanage permissive -a httpd_t
# Tests durchführen und AVCs sammeln
sudo ausearch -m AVC -ts recent > /tmp/avc.log
sudo semanage permissive -d httpd_t
sudo audit2allow -M local_app_fix -i /tmp/avc.log
# .te prüfen, dann installieren
cat local_app_fix.te
sudo semodule -i local_app_fix.pp

# Modul entfernen (Rollback)
sudo semodule -r local_app_fix

Vérifiez attentivement le fichier .te : audit2allow génère des règles sur la base d’activités observées ; ces règles peuvent être trop larges et doivent être RESTreintes manuellement, par exemple en fonction de l’opération (write vs append) ou des objets cibles.

Exemple pratique : le serveur web ne peut pas écrire dans le répertoire d’upload

1. Vérifier le message d’erreur et noter l’heure.
2. Collecter les AVC : ausearch/journal d’audit.
3. Vérifier les contextes : ls -lZ, ps -eZ.
4. Essayer d’abord RESTorecon ; si nécessaire, définir semanage fcontext.
5. Si un accès réseau est nécessaire : vérifier les booleans/ports.
6. Si rien ne convient : passer brièvement en permissive, collecter, construire le module et tester.

# Diagnose-Schritte
ls -lZ /var/www/html/uploads
sudo ausearch -m AVC -ts recent | sudo audit2why
sudo RESTorecon -Rv /var/www/html/uploads
# Falls persistent benoetigt
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
sudo RESTorecon -Rv /var/www/html/uploads

Sauvegarde, RESTauration et migration : conserver les contextes SELinux

Lors de la copie ou de la migration de données, les contextes SELinux sont des attributs étendus (xattrs). Utilisez des outils qui préservent les xattrs, sinon des refus sont probables après la RESTauration.

# Rsync inkl. xattrs, ACLs und besonderen Flags
rsync -aHAX --numeric-ids --delete /srv/source/ /srv/dest/

# Nach RESTore gezielt relabeln
sudo RESTorecon -Rv /srv/dest

Planifiez les migrations avec une exécution de test et des vérifications de relabel ; pour de grands volumes de données, une approche par étapes avec des échantillonnages peut être pertinente.

Supervision, alerting et automatisation

Une analyse régulière des AVC aide à détecter les régressions. Des outils comme auditd/aureport, setroubleshoot (sealert) ou des pipelines de logs centralisés (ELK, Splunk) sont utiles. Définissez dans votre supervision des seuils pour les taux d’AVC et générez des tickets en cas de pics soudains.

# Schnelle Übersicht
sudo aureport --avc --summary

# sealert für verständliche Hinweise
sudo sealert -a /var/log/audit/audit.log | head -n 200

Documentez chaque modification (semanage, setsebool, semodule) dans votre CMDB/ticket de changement en incluant les raisons, la VM de test et le plan de rollback.

Gestion de configuration : exemple de tâche Ansible

- name: Persistente SELinux-Fcontext für Uploads setzen
  become: true
  command: >
    semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
  changed_when: false

- name: RESTorecon auf Uploads anwenden
  become: true
  command: RESTorecon -Rv /var/www/html/uploads

Dans les playbooks d’automatisation, testez l’idempotence et vérifiez les modifications par des dry-runs (RESTorecon -vn) avant de déployer en production.

Liste de contrôle finale avant modification en production

• Joindre la sauvegarde du journal AVC au ticket.
• Vérifier la priorité du correctif : Label → Port → booléen → module.
• N’utiliser le mode permissive que brièvement et de manière documentée.
• Placer les fichiers de module (.te/.pp) dans Git, faire des revues et utiliser des VM de test.
• Vérifier le rollback et l’indiquer dans le ticket.

Conclusion

SELinux offre une sécurité additionnelle forte, mais nécessite un travail systématique : diagnostic basé sur les logs, correction privilégiée via label/port/booléen, collecte ciblée en mode permissif et seulement ensuite des modules de politique allégés. En particulier pour les workloads conteneurisés, planifiez la conformité SELinux dès la phase d’architecture. Versionnez, testez et documentez chaque modification de politique afin que l’exploitation, les sauvegardes/RESTaurations et les audits RESTent fiables.

FAQ

Voir la FAQ à la fin de l’article pour des réponses rapides aux questions fréquentes.

Diagnostiquer les erreurs SELinux : CI/CD, déploiement et gouvernance

Au-delà des corrections ponctuelles, il est pertinent d’intégrer les artefacts SELinux dans vos processus d’exploitation et de déploiement. Cela réduit le risque à long terme, assure la reproductibilité et empêche des modifications de politique larges et non maîtrisées en production.

Modules de politique dans CI : collecte, revue, build

Automatisez la génération et la vérification des propositions de politique. Architecture : tests dans un environnement de staging isolé (idéalement identique à la production), autoriser brièvement des domaines en mode permissif, collecter les AVC, utiliser audit2allow comme point de départ, vérifier le fichier .te dans le repository puis ne builder qu’après RESTriction manuelle.

# CI-Schritte: Beispiel (vereinfachte Darstellung)
# 1) permissive für Domain setzen (nur Stage)
sudo semanage permissive -a myapp_t
# 2) Integrationstests laufen lassen, AVCs sammeln
sudo ausearch -m AVC -ts recent > avc-stage.log
# 3) audit2allow ausführen und .te erzeugen
sudo audit2allow -M myapp_fix -i avc-stage.log
# 4) statische Prüfung (Developer/Reviewer prüft myapp_fix.te)
# 5) Build & Paket
checkmodule -M -m -o myapp_fix.mod myapp_fix.te
semodule_package -o myapp_fix.pp -m myapp_fix.mod

Le fichier .te généré doit être ajouté au Git, y compris les commentaires de revue et les tests, avant d’installer le .pp en staging.

Déploiement sécurisé : Canary, Monitoring, Revert

• Effectuez un déploiement Canary : installez d’abord le module sur un petit groupe d’hôtes.
• Suivez les taux d’AVC et les métriques métier en parallèle ; configurez des alertes en cas d’augmentations soudaines.
• Testez la procédure de revert : semodule -r modulname doit supprimer proprement le module sans effets secondaires et rétablir la fonctionnalité.

Convention de versionnement et de nommage

Nommez les modules avec le service, le numéro de ticket et la version (p. ex. myapp_fix-T1234-v1). Conservez les .te/.pp et les logs d’audit dans le ticket de changement/repo afin que l’audit et le postmortem soient traçables.

Vérifier la diversité : distributions, noyau, moteurs de conteneurs

Les subtilités des politiques SELinux peuvent varier entre RHEL/CentOS, Fedora et Debian/Ubuntu (paquets de politique et booleans différents). Testez les modules sur la matrice représentant votre parc : version de la distro × version du noyau × moteur de conteneur (Docker/Podman) × type de stockage (local/NFS).

Risques opérationnels et limites strictes

Surveillez l’érosion des privilèges : des règles Allow larges (p. ex. allow container_t self:process) élargissent la surface d’attaque. Limitez les règles aux classes d’objet, opérations et motifs de chemin concrets. Documentez les règles d’exception avec l’évaluation des risques, les fenêtres temporelles et la propriété pour les revues ultérieures.

Contrôles préalables automatisés

Avant les installations en production, mettez en place des contrôles préalables automatisés : semodule -l (avant/après), exécutions de test des cas d’utilisation critiques, ainsi qu’une analyse diff automatique des .te générés sur des motifs autorisés. Ces contrôles s’intègrent facilement dans des pipelines CI et évitent une inflation involontaire des politiques.

De telles mesures de gouvernance rendent les modifications SELinux transparentes, reproductibles et plus sûres pour l’exploitation et la conformité — un avantage clair pour les exploitants de logiciels d’entreprise sur mesure et les solutions logicielles proches des processus.

Pour ce sujet, les Selinux Denial et l’analyse d’Audit.log sont également importants. L’article situe ces aspects de manière compréhensible et indique ce qui importe au quotidien.