SELinux ohne Angst: Eigene Policies fur kritische Dienste

Jedes Mal wenn ein Dienst auf RHEL oder Rocky kaputtgeht, ist der Reflex des Bereitschaftsteams derselbe: setenforce 0, Problem gelost, Ticket zu. Sechs Monate spater lauft der gesamte Cluster im Permissive-Modus, niemand erinnert sich warum, und der Compliance-Bericht wird zu Science-Fiction. Das Basilisk OffSec Team hat die letzten zwei Jahre damit verbracht, solche Umgebungen in autorisierten Red Teams umzukippen, und die Schlussfolgerung ist unmissverstandlich: ausgeschaltetes SELinux verkurzt den Weg von einem PHP-FPM RCE bis root auf unter 90 Sekunden. Dieser Artikel verkauft keine Magie, er zeigt den Workflow, mit dem wir versionierte .pp Module in Produktion ausliefern, ohne Deployments zu zerstoren.

Bevor du irgendeine Policy schreibst, musst du lesen was bereits existiert. Der Befehl seinfo -t listet rund 5.000 Typen auf RHEL 9 Standard, und sesearch --allow -s httpd_t zeigt genau, was Apache anfassen darf. Wir beginnen jede Untersuchung mit ausearch -m AVC -ts recent parallel zum Dienst im VORUBERGEHENDEN Permissive-Modus, niemals dem ganzen System. Nutze semanage permissive -a httpd_t um ausschliesslich die untersuchte Domain zu isolieren. Dieses Muster hat ganze Audits gerettet, die wir in Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen beschreiben, wo CIS globales Enforcing verlangt, aber dokumentierte Ausnahmen pro Domain erlaubt.

audit2allow ist ein zweischneidiges Messer. ausearch -m AVC | audit2allow -M meinmodul auszufuhren erzeugt ein .te, das kompiliert und funktioniert, aber haufig absurde Rechte vergibt wie allow httpd_t shadow_t:file read. Unsere interne Checkliste verlangt, dass jedes .te eine manuelle Review durchlauft, bevor semodule -i lauft. Suche nach Regeln, die shadow_t, etc_t, kernel_t oder self:capability sys_admin beruhren, das sind rote Flaggen. In einer kurzlichen Untersuchung, teilweise dokumentiert in DFIR unter Linux: Live-Triage mit UAC und Velociraptor, hatte ein blind generiertes Modul Zugriff auf /etc/sudoers freigegeben und niemand hat es acht Monate lang bemerkt.

Fur neue Dienste schreiben wir die Policy lieber von Grund auf mit der Makro-Sprache von refpolicy. Ein typisches Modul besteht aus drei Dateien: meinservice.te mit den Regeln, meinservice.fc mit den File-Contexts und meinservice.if mit Interfaces fur andere Domains. make -f /usr/share/selinux/devel/Makefile erzeugt das .pp, das du mit semodule -i installierst. Wir versionieren diese drei Dateien in git neben Ansible, und jeder PR lasst checkmodule -M -m und sediff gegen die Baseline laufen. Dieser Prozess hangt mit dem zusammen, was wir in Supply Chain Security: Sigstore-Signatur und echte SBOMs in CI/CD zeigen, wo das .pp am Ende mit Sigstore signiert wird, bevor es die Nodes erreicht.

Dienste, die Sockets auf nicht standardisierten Ports offnen, sind der haufigste Fall von stillem Bruch. Postgres auf 5433 zum Beispiel braucht semanage port -a -t postgresql_port_t -p tcp 5433, keine neue Policy. Nginx, das Dateien ausserhalb von /var/www ausliefert, will semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?" gefolgt von restorecon -Rv /srv/app. Achtzig Prozent der Falle, die wir sehen, sind File-Context und Port-Labeling, keine neue Policy. Das Team, das diesen Unterschied versteht, spart Stunden, und das Thema kehrt zuruck, wenn wir internes Pivoting in Nmap Fortgeschritten: NSE Skripte fur internes Recon im simulierten Firmenlab besprechen.

Wartung in Produktion verlangt Observability. Wir konfigurieren setroubleshoot-server im Silent-Modus, der AVCs uber journald an das SIEM weiterleitet, mit Sigma-Regeln, die auf unerwartete Denials abgestimmt sind. Wenn ein Deploy bricht, kommt der Alarm bevor der User sich beschwert. Wir lassen ausserdem sealert -a /var/log/audit/audit.log wochentlich im Staging laufen, um Policy-Drift abzufangen. Diese kontinuierliche Feedback-Schleife ist genau das, was wir in Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus verteidigen: das Red Team findet den Weg, das Blue Team schreibt die Policy, und die Policy geht in die Pipeline.

Praktisches Fazit: lass setenforce 0 nie langer als 15 Minuten in Produktion laufen. Nutze semanage permissive -a domain_t um das Problem zu isolieren, fang AVCs mit ausearch ein, prufe die audit2allow Ausgabe manuell, committe das .te in git, signiere das .pp und deploye uber Ansible. Wenn du nicht jede Allow-Regel im Code-Review rechtfertigen kannst, ist die Policy nicht bereit. SELinux ist kein Hindernis, es ist der letzte Perimeter, nachdem der Angreifer schon drinnen ist.