SELinux in Produktion — der Workflow, der tatsächlich funktioniert, und die AVC-Denials, die wir immer wieder finden

„Setenforce 0" ist keine Sicherheits-Strategie. Es ist allerdings der häufigste „Fix", den wir für SELinux-Denials auf Kunden-Hosts sehen. Die Begründung ist immer dieselbe: Eine Anwendung brach, die Fehlermeldung erwähnte SELinux, jemand deaktivierte SELinux, die Anwendung lief wieder, und niemand ist zurückgekehrt.

Dies ist der SELinux-Workflow, den wir auf jedem gemanagten RHEL-Host nutzen. Die Prämisse: SELinux bleibt im enforcing-Modus. Custom Policy ist klein und versioniert. Debugging folgt einem bekannten Satz von Schritten, in Reihenfolge.

Ein AVC-Denial debuggen

# Schritt 1 — was wurde verweigert?
ausearch -m AVC -ts recent | grep denied
 
# Schritt 2 — die menschenlesbare Erklärung holen
sealert -a /var/log/audit/audit.log
 
# Schritt 3 — ein Kandidaten-Policy-Modul generieren (vor dem Anwenden prüfen)
ausearch -m AVC -ts recent | audit2allow -M my_app_policy
# LESEN SIE DIE my_app_policy.te-DATEI. Wenden Sie sie nicht einfach an.
 
# Schritt 4 — wenn die Policy vernünftig ist, sie installieren
semodule -i my_app_policy.pp

Schritt 3 ist der, den die meisten Teams überspringen. audit2allow generiert gerne eine Policy, die viel zu breit ist. Prüfen Sie die .te-Datei. Schneiden Sie weg, was nicht da sein sollte. Dann anwenden.

Der vollständige Beitrag behandelt:

• Den fünfstufigen Debug-Workflow in Reihenfolge (und was zu tun ist, wenn Schritt 4 nicht reicht)
• Die Targeted Policy — was sie abdeckt und wo sie zu erweitern ist
• semanage fcontext-Patterns für nicht-standardmäßige Dateipfade
• SELinux-Booleans (getsebool -a | grep <service>) für die einfachen Fixes
• Datei-Kontexte, die ein restorecon überstehen
• Die überwachte Boolean-Liste, auf die wir alarmieren (eines auszuschalten ist eine rote Flagge)

Wir fahren diesen Workflow auf jedem gemanagten RHEL-Host. SELinux bleibt an.