Erste Schritte mit SELinux

Das Fedora-Dokumentationsteam, Peter Boy (pboy) Version F35-F38 Last review: 2023-09-08

Einführung in SELinux

Security-Enhanced Linux (SELinux) bietet eine zusätzliche Sicherheitsebene für das System. SELinux beantwortet im Wesentlichen die Frage: Darf <Subjekt> <Aktion> an <Objekt> ausführen? Zum Beispiel: Darf ein Webserver auf Dateien in den Home-Verzeichnissen der Benutzer zugreifen?

Die standardmäßige Zugriffsrichtlinie, die auf Benutzer-, Gruppen- und anderen Berechtigungen basiert und als Discretionary Access Control (DAC) bekannt ist, ermöglicht es Systemadministratoren nicht, umfassende und fein abgestufte Sicherheitsrichtlinien zu erstellen, wie zum Beispiel die Beschränkung bestimmter Anwendungen auf das Anzeigen von Protokolldateien, während anderen Anwendungen das Anhängen neuer Daten an die Protokolldateien gestattet wird.

SELinux implementiert Mandatory Access Control (MAC). Jeder Prozess und jede Systemressource besitzt ein spezielles Sicherheitslabel, den sogenannten SELinux-Kontext. Ein SELinux-Kontext, auch SELinux-Label genannt, ist ein Identifikator, der die Systemdetails abstrahiert und sich auf die Sicherheitseigenschaften der Entität konzentriert. Dies ermöglicht nicht nur eine konsistente Referenzierung von Objekten in der SELinux-Richtlinie, sondern beseitigt auch Mehrdeutigkeiten, die bei anderen Identifikationsmethoden auftreten können. Beispielsweise kann eine Datei auf einem System mit Bind-Einhängungen mehrere gültige Pfadnamen haben.

Die SELinux-Richtlinie verwendet diese Kontexte in einer Reihe von Regeln, die festlegen, wie Prozesse untereinander und mit den verschiedenen Systemressourcen interagieren können. Standardmäßig erlaubt die Richtlinie keine Interaktion, es sei denn, eine Regel gewährt explizit Zugriff.

Es ist wichtig zu beachten, dass SELinux-Richtlinienregeln erst nach den DAC-Regeln geprüft werden. SELinux-Richtlinienregeln kommen nicht zum Einsatz, wenn DAC-Regeln den Zugriff bereits verweigern. Das bedeutet, dass keine SELinux-Verweigerung protokolliert wird, wenn bereits die herkömmlichen DAC-Regeln den Zugriff verhindern.

SELinux-Kontexte enthalten mehrere Felder: Benutzer, Rolle, Typ und Sicherheitsstufe. Die SELinux-Typinformationen sind für die SELinux-Richtlinie besonders wichtig, da die gängigste Richtlinienregel, die die zulässigen Interaktionen zwischen Prozessen und Systemressourcen definiert, SELinux-Typen und nicht den vollständigen SELinux-Kontext verwendet. SELinux-Typen enden üblicherweise mit _t. Beispielsweise lautet der Typname für den Webserver httpd_t. Der Typkontext für Dateien und Verzeichnisse, die sich normalerweise in /var/www/html/ befinden, ist httpd_sys_content_t. Die Typkontexte für Dateien und Verzeichnisse, die sich normalerweise in /tmp und /var/tmp/ befinden, sind tmp_t. Der Typkontext für Webserver-Ports ist http_port_t.

Es gibt beispielsweise eine Richtlinienregel, die Apache (den Webserverprozess, der als httpd_t läuft) den Zugriff auf Dateien und Verzeichnisse erlaubt, deren Kontext normalerweise in /var/www/html/ und anderen Webserver-Verzeichnissen (httpd_sys_content_t) zu finden ist. Für Dateien, die sich normalerweise in /tmp und /var/tmp/ befinden, gibt es in der Richtlinie keine entsprechende Regel, daher ist der Zugriff nicht gestattet. Selbst wenn Apache kompromittiert wird und ein Schadskript Zugriff erlangt, kann es dank SELinux nicht auf das Verzeichnis /tmp zugreifen.

SELinux_Apache_MariaDB_example
Abbildung 1. SELinux erlaubt dem Apache-Prozess, der als httpd_t ausgeführt wird, den Zugriff auf das Verzeichnis /var/www/html/, verweigert ihm aber den Zugriff auf das Verzeichnis /data/mysql/, da keine entsprechende Regel für die Kontexttypen httpd_t und mysqld_db_t existiert. Der MariaDB-Prozess, der als mysqld_t ausgeführt wird, kann hingegen auf das Verzeichnis /data/mysql/ zugreifen, und SELinux verweigert diesem Prozess mit dem Typ mysqld_t korrekterweise den Zugriff auf das Verzeichnis /var/www/html/, das als httpd_sys_content_t gekennzeichnet ist.

Weitere Ressourcen

Um die grundlegenden Konzepte von SELinux besser zu verstehen, lesen Sie bitte die folgende Dokumentation:

Vorteile der Ausführung von SELinux

SELinux hat die folgenden Vorteile:

  • Alle Prozesse und Dateien sind gekennzeichnet. SELinux-Richtlinienregeln definieren, wie Prozesse mit Dateien und untereinander interagieren. Der Zugriff ist nur dann erlaubt, wenn eine entsprechende SELinux-Richtlinienregel existiert.

  • Feinkörnige Zugriffskontrolle. SELinux geht über die traditionellen UNIX-Berechtigungen hinaus, die nach Ermessen des Benutzers und basierend auf Linux-Benutzer- und Gruppen-IDs gesteuert werden, und stützt sich bei den Zugriffsentscheidungen auf alle verfügbaren Informationen, wie z. B. SELinux-Benutzer, Rolle, Typ und optional eine Sicherheitsstufe.

  • Die SELinux-Richtlinie wird administrativ definiert und systemweit durchgesetzt.

  • Verbesserter Schutz vor Privilege-Escalation-Angriffen. Prozesse laufen in Domains und sind somit voneinander getrennt. SELinux-Richtlinienregeln definieren den Zugriff von Prozessen auf Dateien und andere Prozesse. Wird ein Prozess kompromittiert, hat der Angreifer nur Zugriff auf dessen normale Funktionen und auf die Dateien, für die der Prozess konfiguriert wurde. Wird beispielsweise der Apache HTTP Server kompromittiert, kann ein Angreifer diesen Prozess nicht zum Lesen von Dateien in Benutzerverzeichnissen verwenden, es sei denn, eine spezifische SELinux-Richtlinienregel wurde hinzugefügt oder konfiguriert, um einen solchen Zugriff zu erlauben.

  • SELinux kann verwendet werden, um die Vertraulichkeit und Integrität von Daten durchzusetzen und Prozesse vor nicht vertrauenswürdigen Eingaben zu schützen.

Jedoch ist SELinux Folgendes nicht:

  • Antivirus-Software,

  • ein Ersatz für Passwörter, Firewalls und andere Sicherheitssysteme,

  • ein komplette Sicherheitslösung.

SELinux ist darauf ausgelegt, bestehende Sicherheitslösungen zu ergänzen, nicht zu ersetzen. Auch bei der Verwendung von SELinux ist es wichtig, weiterhin bewährte Sicherheitspraktiken anzuwenden, wie zum Beispiel Software aktuell zu halten, sichere Passwörter zu verwenden oder Firewalls einzusetzen.

SELinux-Beispiele

Die folgenden Beispiele veranschaulichen, wie SELinux die Sicherheit erhöht:

  • Die Standardaktion ist Verweigerung. Wenn keine SELinux-Richtlinienregel existiert, die den Zugriff erlaubt, beispielsweise für einen Prozess, der eine Datei öffnet, wird der Zugriff verweigert.

  • SELinux kann Linux-Benutzer einschränken. In den SELinux-Richtlinien sind mehrere eingeschränkte SELinux-Benutzer definiert. Linux-Benutzer können diesen eingeschränkten SELinux-Benutzern zugeordnet werden, um die für sie geltenden Sicherheitsregeln und -mechanismen zu nutzen. Beispielsweise führt die Zuordnung eines Linux-Benutzers zum SELinux-Benutzer user_u dazu, dass dieser Benutzer keine Anwendungen mit Set-User-ID (setuid) wie sudo und su ausführen kann (sofern nicht anders konfiguriert). Außerdem wird verhindert, dass er Dateien und Anwendungen in seinem Home-Verzeichnis ausführt. Bei entsprechender Konfiguration wird so verhindert, dass Benutzer schädliche Dateien aus ihren Home-Verzeichnissen ausführen.

  • Verbesserte Trennung von Prozessen und Daten. Prozesse laufen in eigenen Domains, wodurch verhindert wird, dass Prozesse auf Dateien zugreifen, die von anderen Prozessen verwendet werden, und umgekehrt. Beispielsweise kann ein Angreifer bei aktiviertem SELinux, sofern nicht anders konfiguriert, keinen Samba-Server kompromittieren und diesen anschließend als Einfallstor für Angriffe nutzen, um auf Dateien zuzugreifen, die von anderen Prozessen, wie etwa MariaDB-Datenbanken, verwendet werden.

  • SELinux hilft, die Folgen von Konfigurationsfehlern zu minimieren. DNS-Server (Domain Name System) replizieren häufig Informationen untereinander, was als Zonentransfer bezeichnet wird. Angreifer können Zonentransfers nutzen, um DNS-Server mit falschen Informationen zu aktualisieren. Wenn der Berkeley Internet Name Domain (BIND) als DNS-Server unter Fedora ausgeführt wird, verhindert die standardmäßige SELinux-Richtlinie, dass Zonendateien ([1]) durch Zonentransfers aktualisiert werden – selbst wenn ein Administrator vergisst, die Durchführung von Zonentransfers auf bestimmte Server einzuschränken. Dies gilt sowohl für den BIND-Daemon named selbst als auch für andere Prozesse.

  • Siehe den NetworkWorld.com-Artikel, A seatbelt for server software: SELinux blocks real-world exploits[2], für Hintergrundinformationen zu SELinux und Informationen zu diversen Angriffen, die SELinux verhindert hat.

SELinux-Architektur

SELinux ist ein Linux-Sicherheitsmodul (LSM), das in den Linux-Kernel integriert ist. Das SELinux-Subsystem im Kernel wird durch eine Sicherheitsrichtlinie gesteuert, die vom Administrator festgelegt und beim Systemstart geladen wird. Alle sicherheitsrelevanten Zugriffsoperationen auf Kernel-Ebene werden von SELinux abgefangen und im Kontext der geladenen Sicherheitsrichtlinie geprüft. Ist die Operation durch die geladene Richtlinie erlaubt, wird sie ausgeführt. Andernfalls wird die Operation blockiert und der Prozess erhält eine Fehlermeldung.

SELinux-Entscheidungen, wie das Erlauben oder Verweigern von Zugriffen, werden zwischengespeichert. Dieser Cache wird als Access Vector Cache (AVC) bezeichnet. Durch die Verwendung dieser zwischengespeicherten Entscheidungen müssen SELinux-Richtlinienregeln seltener überprüft werden, was die Leistung steigert. Beachten Sie, dass SELinux-Richtlinienregeln wirkungslos bleiben, wenn zuvor bereits DAC-Regeln den Zugriff verweigern.

SELinux-Status und -Modi

SELinux kann in einem von drei Modi ausgeführt werden: disabled, permissive oder enforcing.

Der deaktivierte Modus wird dringend abgeraten; dadurch wird nicht nur die Durchsetzung der SELinux-Richtlinie verhindert, sondern auch die Kennzeichnung persistenter Objekte wie Dateien unterlassen, was die spätere Aktivierung von SELinux erschwert.

Im permissiven Modus verhält sich das System so, als ob SELinux die geladene Sicherheitsrichtlinie durchsetzt, einschließlich der Kennzeichnung von Objekten und der Ausgabe von Zugriffsverweigerungseinträgen in den Protokollen, verweigert aber tatsächlich keine Operationen. Obwohl der permissive Modus für Produktionssysteme nicht empfohlen wird, kann er bei der Entwicklung von SELinux-Richtlinien hilfreich sein.

Der Erzwingungsmodus ist der Standardbetriebsmodus und wird empfohlen; im Erzwingungsmodus arbeitet SELinux normal und setzt die geladene Sicherheitsrichtlinie auf dem gesamten System durch.

Verwenden Sie den Befehl setenforce, um zwischen dem Erzwingungs- und dem permissiven Modus zu wechseln. Änderungen, die mit setenforce vorgenommen werden, bleiben nach einem Neustart nicht erhalten. Um in den Erzwingungsmodus zu wechseln, geben Sie als Linux-Root-Benutzer den Befehl setenforce 1 ein. Um in den permissiven Modus zu wechseln, geben Sie den Befehl setenforce 0 ein. Verwenden Sie den Befehl getenforce, um den aktuellen SELinux-Modus anzuzeigen:

[~]# getenforce
Enforcing
[~]# setenforce 0
[~]# getenforce
Permissive
[~]# setenforce 1
[~]# getenforce
Enforcing

In Fedora können Sie einzelne Domains in den permissiven Modus versetzen, während das System im Erzwingungsmodus läuft. Um beispielsweise die Domain httpd_t in den permissiven Modus zu versetzen:

[~]# semanage permissive -a httpd_t
1. Textdateien, die Informationen wie die Zuordnung von Hostnamen zu IP-Adressen enthalten und von DNS-Servern verwendet werden
2. Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Veröffentlicht am 24. Februar 2008. Zugegriffen am 27. August 2009: https://www.networkworld.com/article/2283723/lan-wan/a-seatbelt-for-server-software--selinux-blocks-real-world-exploits.html.

Want to help? Learn how to contribute to Fedora Docs ›