Linux mit SELinux härten: Ein vollständiger und praktischer Leitfaden

Informatec Digital » Ressourcen » Linux mit SELinux härten: Ein vollständiger und praktischer Leitfaden

Wenn Sie einen Linux-Server für den Produktivbetrieb einrichten, ist seine Standardkonfiguration in der Regel recht offen. Er ist darauf ausgelegt, sofort einwandfrei zu funktionieren, nicht als Festung . Hier kommt SELinux als wichtige Komponente zur Systemhärtung ins Spiel: Es fügt eine zusätzliche Kontrollebene hinzu, die auch dann noch funktioniert, wenn typische Schutzmechanismen (Dateiberechtigungen, Firewall, Updates ) versagen.

SELinux mag auf den ersten Blick komplex erscheinen, doch sobald man die Grundlagen verstanden hat, erweist es sich als äußerst leistungsstarkes Werkzeug, um Sicherheitslücken einzudämmen, Schäden zu begrenzen und Sicherheitsstandards wie CIS, PCI DSS oder andere kritische Normen zu erfüllen. Anstatt sich darauf zu verlassen, dass Anwendungen sich normal verhalten, zwingt das System jeden Prozess, innerhalb klar definierter Grenzen zu arbeiten.

Was ist SELinux und warum ist es für die Härtung von Linux-Systemen wichtig?

Security-Enhanced Linux (SELinux) ist eine Sicherheitserweiterung des Linux-Kernels, die auf Mandatory Access Control (MAC) basiert. Im Gegensatz zur klassischen Unix Discretionary Access Control (DAC), bei der der Dateibesitzer entscheidet, wer auf eine Datei zugreifen darf, werden die Regeln in SELinux durch eine zentrale Richtlinie vorgegeben, die selbst Root-Benutzer nicht ohne explizite Änderung überschreiben können.

Dieses Modell stellt sicher, dass Zugriffsentscheidungen auf Sicherheitskennzeichnungen (Kontexten) und vordefinierten Regeln basieren und nicht nur auf Lese-, Schreib- und Ausführungsberechtigungen. Selbst wenn ein Dienst kompromittiert wurde oder über übermäßige Berechtigungen verfügt, kann SELinux verhindern, dass er auf sensible Dateien zugreift, andere Prozesse auslöst oder sich über seine autorisierten Grenzen hinaus im Netzwerk ausbreitet.

SELinux ersetzt nicht das herkömmliche DAC, sondern ergänzt es. Zuerst werden die Standard-Unix-Berechtigungen geprüft. Nur wenn DAC die Operation zulässt, greift SELinux ein, um seine Richtlinie zu validieren . Blockiert DAC den Zugriff bereits, interveniert SELinux weder noch protokolliert es etwas. Dies reduziert die Anzahl der Protokolleinträge und erhält die Leistung aufrecht.

Dieser mehrschichtige Ansatz ist besonders in Unternehmensumgebungen wie Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise oder openSUSE Leap erkennbar , wo SELinux in die übrigen Sicherheitsmechanismen des Systems und in moderne Technologien wie Container und virtuelle Maschinen integriert ist.

Schlüsselkonzepte: SELinux-Richtlinien, Kontexte und Domänen

Die Grundlage von SELinux bilden Sicherheitsrichtlinien, die beschreiben, wer was gegen welche Bedrohungen tun darf und wie . In dieser Sprache werden Prozesse als Subjekte und Systemressourcen (Dateien, Verzeichnisse, Sockets, Ports, Geräte usw.) als Objekte betrachtet.

Anstatt Benutzer als „root“ oder „www-data“ zu betrachten, arbeitet SELinux mit Domänen und TypenEin Apache-Webserverprozess läuft beispielsweise in der Domäne httpd_tDie dem Client bereitgestellten Dateien haben hingegen einen Typ wie httpd_sys_content_tDie Richtlinie definiert, welche Domänen auf welche Typen, für welche Objektklassen (Datei, Verzeichnis, Socket, Port usw.) und mit welchen spezifischen Berechtigungen (Lesen, Schreiben, Ausführen, Abrufen von Attributen, Anhängen usw.) zugreifen können.

Jedem Objekt ist ein SELinux-Kontext zugeordnet , eine Bezeichnung der folgenden Form:

usuario:rol:tipo:nivel

Eine Datei könnte beispielsweise so gekennzeichnet sein: system_u:object_r:httpd_sys_content_t:s0Wo Das wichtigste Feld für die tägliche Verwaltung ist in der Regel die Art (httpd_sys_content_t), die festlegt, welchen Prozessdomänen der Zugriff gestattet wird.

In der Praxis arbeitet SELinux mit Tausenden von Regeln. Um die Übersichtlichkeit zu wahren, sind die Richtlinien in unabhängige Module unterteilt, die aktiviert, deaktiviert oder aktualisiert werden können, ohne dass ein riesiger monolithischer Block neu kompiliert werden muss. Dies ist insbesondere in RHEL, SUSE und openSUSE von entscheidender Bedeutung, da dort jeder relevante Dienst typischerweise über ein eigenes Richtlinienmodul verfügt.

SELinux-Betriebsmodi: Erzwingen, Zulassen und Deaktiviert

SELinux kann in drei verschiedenen Modi betrieben werden, die bestimmen, in welchem ​​Umfang seine Regeln in Echtzeit auf das System angewendet werden :

Im Erzwingungsmodus setzt der Kernel die Richtlinie strikt durch. Jede Aktion, die gegen die Regeln verstößt, wird blockiert und protokolliert . Dies ist der empfohlene Modus für den Produktivbetrieb, wenn die Richtlinie optimal konfiguriert ist, da SELinux hier seinen vollen Schutz bietet.

Im permissiven Modus wertet SELinux die Richtlinie weiterhin aus, blockiert aber nichts . Alle Verstöße werden als Warnungen protokolliert. Dieser Modus eignet sich ideal zum Testen, Bereitstellen neuer Anwendungen oder Feinabstimmung von Regeln, da er es ermöglicht, Verstöße gegen die Richtlinien zu erkennen, ohne den Betrieb von Diensten zu unterbrechen.

Im deaktivierten Modus ist SELinux vollständig deaktiviert. Es werden keine Richtlinien durchgesetzt und keine SELinux-bezogenen Protokolle generiert. Der Wechsel zwischen deaktiviertem und aktivem Modus (permissiv oder erzwingend) erfordert einen Neustart, da der Kernel mit initialisierter SELinux-Unterstützung starten muss, um das Dateisystem zu kennzeichnen.

Eine sehr sinnvolle Vorgehensweise bei jeder Distribution ist es, zunächst mit permissiven Einstellungen zu beginnen , die Kennzeichnung und Richtlinienprobleme zu überprüfen und zu beheben und erst dann auf erzwingende Einstellungen umzuschalten, wenn alles stabil läuft . Wenn diese Funktion dauerhaft deaktiviert bleibt, wird eine der wirksamsten Schutzebenen entfernt.

Integration von SELinux in RHEL, Fedora, SUSE und openSUSE

Distributionen wie Red Hat Enterprise Linux, Fedora und deren Derivate aktivieren SELinux standardmäßig und verwenden dabei in der Regel eine gezielte Richtlinie, die hauptsächlich Systemdienste einschränkt, die von systemd gestartet werden, sowie einige Benutzer.

In RHEL stehen neben den vorkonfigurierten Richtlinien verschiedene Tools zur Verfügung, die dem Administrator die ständige Auseinandersetzung mit Low-Level-Regeln ersparen. Besonders hervorzuheben ist der SELinux Troubleshooter, der Zugriffsverweigerungsereignisse analysiert und konkrete Änderungen vorschlägt (z. B. die Aktivierung eines booleschen Werts, die Korrektur eines Kontexts oder die Generierung eines zusätzlichen Moduls).

Darüber hinaus erstreckt sich SELinux auf Container (z. B. mit Podman) und virtualisierte Umgebungen. Mit entsprechenden Tags wird jeder Container oder jede VM auf Kernel-Ebene von den anderen isoliert, selbst wenn eine Schwachstelle in der Laufzeitumgebung oder im Hypervisor ausgenutzt wird.

Im SUSE-Ökosystem ist das SELinux-Framework zwar im Kernel und den Tools von SUSE Linux Enterprise Server integriert , jedoch nicht in einer umfassenden offiziellen Richtlinie. Es empfiehlt sich, eine auf Ihre Umgebung zugeschnittene Richtlinie zu erstellen oder Lösungen wie slemicro zu verwenden, wenn Sie einen minimalistischen Host für Container oder Virtualisierung mit vollständiger SELinux-Unterstützung benötigen.

In openSUSE Leap ist es üblich, für Tests auf Richtlinien zurückzugreifen, die in Repositories wie security:/SELinux_legacy verfügbar sind , wohl wissend, dass für eine kritische Umgebung eine speziell auf die jeweilige Bereitstellung abgestimmte Richtlinie immer noch ideal ist.

SELinux-Richtlinienmodelle: gezielt, MLS und minimal

SELinux kann mit verschiedenen Richtlinienmodellen arbeiten, die den Umfang und die Tiefe der Kontrolle bestimmen. Die drei gängigsten sind:

Die gezielte Richtlinie ist für allgemeine Umgebungen konzipiert. Sie konzentriert sich auf die Einschränkung bestimmter Dienste (insbesondere Netzwerkdienste) und lässt andere Prozesse in permissiveren Bereichen oder sogar unbeschränkt. Sie ist in den meisten Distributionen die Standardoption, da sie ein gutes Gleichgewicht zwischen Sicherheit und Kompatibilität bietet.

La Multi-Level Security (MLS)-Richtlinie Fügen Sie das Feld für die Sensibilitätsstufe zum Kontext hinzu (s0, s1, s2, Kategorien usw.) und erlaubt Informationen und Prozesse in Ebenen einteilenEs ist für Organisationen mit sehr strengen Anforderungen (Verteidigung, Nachrichtendienste, Verschlusssachen) konzipiert, bei denen es darauf ankommt, wer welche Daten einsehen oder verändern darf.

Die Minimalrichtlinie ist eine reduzierte Variante mit weniger Regeln und Kontrollen. Sie wird in Systemen mit geringen Sicherheitsanforderungen oder bei minimalen Auswirkungen auf die Kompatibilität eingesetzt , wobei einige der Isolationsfunktionen von SELinux eingeschränkt werden.

In realen Einsatzszenarien ist es in der Regel vorzuziehen, mit gezielten modularen Richtlinien zu arbeiten und Modul für Modul anzupassen, was und wie geschützt wird, anstatt zu versuchen, eine einzige riesige monolithische Datei zu verwalten, die viel schwieriger zu pflegen ist.

Kontextverwaltung: Anzeigen, Ändern und Wiederherstellen von SELinux-Tags

Eine der Hauptaufgaben bei der SELinux-Administration besteht darin, sicherzustellen, dass Dateien, Verzeichnisse, Prozesse und Ports gemäß der Richtlinie den korrekten Kontext besitzen. Ein falsch zugewiesener Kontext kann dazu führen, dass ein Dienst nicht mehr funktioniert oder eine Ressource zu stark exponiert ist.

Um den SELinux-Kontext von Dateien und Verzeichnissen zu untersuchen, akzeptieren viele Standardbefehle die Option -Z. Zum Beispiel mit ls -Z /ruta können Sie sehen, Benutzer, Rolle, Typ und Ebene jedes Eintragsund mit ps Zaux Sie erhalten den Kontext der aktiven Prozesse.

Wenn eine Richtlinie installiert und das Dateisystem gekennzeichnet wird (z. B. mithilfe von …), setfiles o fixfiles mit den Dateien file_contexts), jede Route erhält eine Standardtyp gemäß RichtlinieWenn Sie eine neue Datei in einem bereits benannten Verzeichnis erstellen, erbt diese den Verzeichnistyp. Wenn Sie die Datei jedoch von einem anderen Speicherort verschieben, behält sie ihre ursprüngliche Bezeichnung, was zu Inkonsistenzen führen kann.

Falls eine Datei oder ein Verzeichnisbaum die falschen Bezeichnungen hat, können Sie diese mit folgender Funktion korrigieren: restoreconDass Stellt Kontexte auf die in der Richtlinie definierten Werte wieder her.. Mit Optionen wie -R (rekursiv) und -v (ausführlich) Die Änderungen sind leicht zu erkennen. Dies ist ein nahezu obligatorischer Schritt vor dem Wechsel vom permissiven in den erzwingenden Modus bei Systemen, die sich bereits seit einiger Zeit in der Testphase befinden.

Um neue Beschriftungsmuster zu deklarieren, verwenden Sie semanage fcontextMit diesem Tool schreiben Sie in die Richtlinie, was Der SELinux-Typ muss bestimmten Pfaden oder regulären Ausdrücken zugewiesen werden.und dann wenden Sie diese Änderungen auf das Dateisystem an mit restoreconSie können beispielsweise ein neues Element kennzeichnen. DocumentRoot von Apache mit httpd_sys_content_t damit der Webserver es innerhalb seiner begrenzten Domäne lesen kann.

Grundkonfiguration: SELinux aktivieren und Modus auswählen

Das Verhalten von SELinux auf globaler Ebene wird gesteuert von /etc/selinux/config, wobei der Modus definiert ist (enforcing, permissive o disabled) und die anzuwendende Richtlinie (zielgerichtet, MLS, Minimum…).

In Systemen wie RHEL oder Fedora kommt die Zielrichtlinie normalerweise Standardmäßig aktiviert und im ErzwingungsmodusUnter SUSE oder openSUSE müssen die Kernelparameter in GRUB2 angepasst werden, um SELinux anstelle von AppArmor zu laden. Dies erfordert das Hinzufügen von Optionen wie beispielsweise security=selinux y selinux=1 zur Bootzeile zurückkehren und die GRUB-Konfiguration neu generieren.

Nach der Aktivierung von SELinux beim Systemstart und der Auswahl der Richtlinie ist es wichtig, ein erstes vollständiges Dateisystem-Tag durchzuführen. setfiles oder gleichwertige Werkzeuge. Dieser Schritt Das kann Zeit in Anspruch nehmen und am besten macht man es in einer Zeit geringer Nachfrage.Aber es ist die Grundlage dafür, dass das System im Forcing-Modus ohne Überraschungen startet.

In Umgebungen, in denen Sie von AppArmor migrieren, ist dies von entscheidender Bedeutung. Überprüfen Sie die Dateien sehr sorgfältig. file_contexts und deren lokale VariantenDenn jede schwerwiegende Inkonsistenz kann den Systemstart verhindern. Erstellen Sie vorher ein Backup und arbeiten Sie mit semanage fcontext Die Anpassung der Politik an die Realität des Systems ist nahezu unerlässlich.

SELinux und CVEs: Wie sie zur Minderung von Sicherheitslücken beitragen

Anbieter wie Red Hat beziehen SELinux in ihre CVEs-Auswirkungsanalyse mit ein . Ihr Schweregradmodell (Kritisch, Wichtig, Mittel, Niedrig) berücksichtigt, ob eine Schwachstelle durch gut konfigurierte SELinux-Beschränkungen entschärft oder zumindest eingedämmt werden kann.

Bei einer kritischen Sicherheitslücke zur Remotecodeausführung, Typ Log4Shell (CVE-2021-44228)Ein Angreifer könnte Code in einen über das Internet erreichbaren Dienst einschleusen. Läuft dieser Dienst unter einer stark eingeschränkten SELinux-Domäne, ist das Schadenspotenzial reduziert, denn wird keine Berechtigung zum Lesen haben /etc/shadowsensible Datenbanken manipulieren oder sich im System bewegen außerhalb dessen, was für seine Funktion unbedingt notwendig ist.

Bei Schwachstellen zur Rechteausweitung wie CVE-2023-4911 (Looney Tunables) kann die Richtlinie selbst dann, wenn der Exploit einem Benutzer auf DAC-Ebene höhere Berechtigungen verschafft, wichtige Aktionen wie das Laden von Kernelmodulen, das Schreiben in Systemverzeichnisse oder das Öffnen bestimmter Netzwerk-Sockets verhindern . Dies schränkt die Möglichkeiten ein, die mit den neu erlangten Zugriffsrechten genutzt werden können.

Bei mittelschweren Sicherheitslücken (beispielsweise bestimmten Problemen in Grafana), die ungewöhnliche Konfigurationen erfordern oder schwer auszunutzen sind, fungiert SELinux als zusätzliche Schutzbarriere und verhindert, dass sich eine kleinere Schwachstelle zu einem schwerwiegenden Vorfall ausweitet. Häufig blockiert die Richtlinie direkt den Zugriff, den ein Angreifer benötigen würde, um das System zu kompromittieren.

Bei Sicherheitslücken mit geringen Auswirkungen, wie etwa Fehlern, die zum Absturz von Benutzeranwendungen führen (zum Beispiel in Editoren wie vim) , ist SELinux in der Regel nicht ausschlaggebend für die Verhinderung des Problems selbst, behält aber dennoch seine Eindämmungsfunktion bei und stellt sicher, dass ein fehlerhafter Prozess seine konzeptionelle Sandbox nicht verlässt.

SELinux in Aktion: Ein praktisches Beispiel für die Abschottung eines Webservers

Stellen Sie sich einen Webserver vor, der unter RHEL oder Fedora läuft und mehrere Anwendungen bereitstellt. Trotz installierter Patches ist eine seiner Komponenten anfällig für eine Sicherheitslücke, die die Ausführung von Schadcode aus der Ferne ermöglicht. Ohne SELinux könnte ein Angreifer, der Code als Benutzer des Webservers ausführt, Hintertüren installieren, Zugangsdaten auslesen oder auf andere Systeme zugreifen.

Mit SELinux im Erzwingungsmodus und einer gut abgestimmten zielgerichteten Richtlinie laufen Apache, Nginx oder ähnliche Prozesse unter der Domain httpd_t, Welche hat Berechtigungen beschränkt auf Dateien, die mit Typen wie z.B. gekennzeichnet sind httpd_sys_content_t o httpd_sys_rw_content_tund kontrollierter Zugriff auf definierte Ports ebenfalls im entsprechenden Kontext.

Dies bedeutet, dass, obwohl die Sicherheitslücke die Ausführung von Befehlen ermöglicht, der kompromittierte Prozess Es kann keine Dateien wie diese lesen /etc/shadow noch berühren Datenbankverzeichnisse gekennzeichnet mit spezifischen Typen (zum Beispiel mysqld_db_t), noch beliebige Verbindungen zu anderen internen Diensten zu öffnen, wenn die Netzwerkrichtlinie dies einschränkt.

Statt einer vollständigen Systemkompromittierung beschränkt sich der Angriff auf die Website-Domain . Zwar muss der Vorfall dennoch untersucht werden, doch die potenziellen Auswirkungen sind deutlich geringer, und der Angreifer hat es wesentlich schwerer, aktiv zu werden.

Boolesche Werte, Module und Werkzeuge zur Anpassung von Richtlinien

Neben der korrekten Kennzeichnung besteht die tägliche Arbeit mit SELinux üblicherweise darin, die Basisrichtlinie für kleinere Anpassungen zu optimieren, ohne sie komplett neu schreiben zu müssen . Hier kommen Boolesche Werte und benutzerdefinierte Module zum Einsatz.

Die Boolesche Werte SELinux Hierbei handelt es sich um Ein-/Ausschalter, die Teile des Verhaltens der bereits kompilierten Richtlinie ändern. Beispielsweise kann ein boolescher Wert dem FTP-Server erlauben oder verbieten, in bestimmte Verzeichnisse zu schreiben (im Fall von …). allow_ftpd_anon_write), oder dass der Webserver ausgehende Verbindungen zum Netzwerk initiiert.

Mit getsebool -a o semanage boolean -l Sie können diese Schalter auflisten und ihre Beschreibungen anzeigen lassen. Um sie dauerhaft zu ändern, verwenden Sie setsebool -P nombre_booleano on|offwo die Option -P stellt sicher, dass die Änderung auf der Festplatte gespeichert wird und auch nach Neustarts erhalten bleibt.Es ist eine sehr bequeme Möglichkeit, die "offizielle" Richtlinie an die spezifischen Bedürfnisse Ihres Servers anzupassen.

Andererseits ist die Verwendung von Richtlinienmodule Es ermöglicht Ihnen, Regeln zu erweitern oder zu ändern, ohne die Basisrichtlinie anzutasten. Sie können die aktiven Module mit folgendem Befehl anzeigen: semodule -lum einen mit semodule -d nombre oder reaktivieren Sie es mit semodule -e nombreBei SUSE/openSUSE ist dies besonders nützlich, um genau festzulegen, welche Teile des Systems im Fokus von SELinux stehen sollen, während Sie Ihre Bereitstellung stabilisieren.

Wenn Sie sehr spezifische zusätzliche Berechtigungen erteilen müssen, ist die Kombination aus audit2allow y semodule Es macht das Leben viel einfacher. Basierend auf den Aufzeichnungen von /var/log/audit/audit.log, audit2allow zeigt Ihnen an, welche Regel blockiert wurde, und generiert ein Modul. Wenn Sie es installieren, ermöglicht es genau das, was zuvor verwehrt war.

Protokollierung, Überwachung und Fehlerbehebung mit SELinux

Jedes Mal, wenn SELinux eine Aktion verhindert, die die Richtlinie nicht autorisiert, AVC-Verweigerung (Zugriffsvektor-Cache-Verweigerung), die normalerweise protokolliert wird in /var/log/audit/audit.logvorausgesetzt, dass der Dienst auditd es funktioniert.

Diese Einträge enthalten viele Informationen: was versucht wurde zu tun (avc: denied { append }, write, getattrusw.), welcher Prozess dies angefordert hat (pid, comm=), um welche Datei oder Ressource es sich handelt (name=, dev=, ino=), Welchem ​​Kontext lag der ursprüngliche Prozess zugrunde?scontext) und in welchem ​​Kontext das Reiseziel liegt (tcontext)Auf den ersten Blick wirken sie wie kryptische Zeilen, aber mit etwas Übung sind sie Gold wert, um zu verstehen, was vor sich geht.

Um nicht verrückt zu werden, weil man das Protokoll manuell durchlesen muss, gibt es Tools wie ausearch Filterung nach Nachrichtentyp ermöglichen (zum Beispiel -m AVC) oder durch ein temporäres Fenster (-ts recentUnd vor allem audit2allow und Dienstprogramme wie sealert helfen zu diese Ereignisse in eine nahezu menschliche Sprache zu übersetzen und Vorschläge anzeigen.

Ein typischer Ablauf zur Fehlerbehebung wäre die Verwendung von audit2allow -w -a Um Erläuterungen zu den neuesten Bekanntmachungen zu sehen, dann audit2allow -a o -i fichero um spezifische Regeln zu überprüfen, und schließlich Entscheiden Sie, ob es sich lohnt, ein Modul zu erstellen, das diese Berechtigung freischaltet. Oder wenn im Gegenteil der Block auf der sicheren Seite ist und man ihn besser nicht anfassen sollte.

Immer wenn Module generiert werden mit audit2allow -M nombre und werden installiert mit semodule -iEs empfiehlt sich, diese Einstellungen zu überprüfen, da das Tool dazu neigt, großzügig zu sein und mehr Zugriffsrechte zu gewähren, als unbedingt notwendig sind. SELinux bietet zwar viel Flexibilität bei der Absicherung des Zugriffs, doch eine unachtsame Verwendung kann zu Sicherheitslücken in den Richtlinien selbst führen.

SELinux im Rahmen einer Linux-Härtungsstrategie

SELinux existiert nicht isoliert: Es ist in eine umfassendere Härtungsstrategie integriert, die Benutzer mit eingeschränkten Rechten, Firewalls, SSH-Härtung, Anti-Brute-Force-Mechanismen und Konfigurationsautomatisierung umfasst.

Ein sehr häufiges Vorgehen nach der Installation eines Servers ist es, einen Benutzer mit eingeschränkten sudo-Rechten anzulegen, um niemals direkt als Root arbeiten zu müssen, eine Netzwerk-Firewall (wie ufw oder iptables/nftables) zu aktivieren , Tools wie Fail2ban zu installieren, um wiederholte Zugriffsversuche zu blockieren, und SSH nach bewährten Methoden zu konfigurieren (nicht standardmäßiger Port, Deaktivierung des Root-Zugriffs, Schlüsselauthentifizierung, Begrenzung der Zugriffsversuche, robuste Verschlüsselung usw.).

Aufbauend auf dieser Grundlage ergänzt SELinux die MAC-Ebene: Selbst wenn ein Angreifer Zugriff auf einen Benutzer mit falsch konfigurierten sudo-Berechtigungen oder einem SSH-Passwort erlangt, kann die Richtlinie weiterhin einschränken, auf welche Prozesse und Dateien dieser Benutzer zugreifen darf . Sie ist zwar nicht unfehlbar, schließt aber viele der Schwachstellen, die typischerweise von automatisierten Angriffen ausgenutzt werden und in Matrizen wie MITRE ATT&CK beschrieben sind.

Mit zunehmender Serveranzahl wird die manuelle Anwendung all dieser Sicherheitsmaßnahmen unpraktisch. Hier kommen Automatisierungs- und Orchestrierungstools (Ansible, Puppet, Chef, kommerzielle automatisierte Sicherheitslösungen usw.) zum Einsatz. Sie ermöglichen die Bereitstellung konsistenter SELinux-Richtlinien, die Anpassung von Booleschen Werten, die Pfadkennzeichnung und die Aufrechterhaltung der gewünschten Zustände, ohne dass Stunden pro Maschine aufgewendet werden müssen.

In Organisationen mit Hunderten von Knoten kann diese Automatisierung den Unterschied ausmachen zwischen einer einigermaßen homogenen und sicheren Umgebung und einem Dschungel inkonsistenter Konfigurationen, bei denen SELinux auf der Hälfte der Server deaktiviert ist, „damit es niemanden stört“.

Letztendlich wird SELinux, wenn es gut implementiert ist – mit Erzwingungsmodus, konsistenten Kontexten, überarbeiteten Richtlinien, feinabgestimmten Modulen und überwachten Protokollen – zu einer Art Sicherheitsnetz, das ungewöhnliches Verhalten fernhält, Eindringversuche eindämmt und dazu beiträgt, zu demonstrieren, dass robuste Zugriffskontrollen für Audits, Vorschriften und bewährte Sicherheitspraktiken angewendet werden .