Linux/SELinux/01 Grundlagen: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| (78 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
'''Linux/SELinux/01 Grundlagen''' | '''Linux/SELinux/01 Grundlagen''' - Security-Enhanced Linux | ||
{{Navigation|SELinux|Linux/SELinux/02 Installation}} | |||
== Beschreibung == | == Beschreibung == | ||
[[SELinux]] (''Security Enhanced Linux'') ist ein System mit | [[SELinux]] (''Security Enhanced Linux'') ist ein System mit | ||
* Mandatory Access Control | * Mandatory Access Control (MAC) | ||
* | * baut auf der LSM-Schnittstelle (''Linux Security Modules'') des [[Linux-Kernel]]s auf | ||
In der Praxis befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen | In der Praxis befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen | ||
== Regeln == | |||
SELinux verwendet einen Satz von Regeln - in ihrer Gesamtheit als ''Policy'' bezeichnet - um Vorgänge zu autorisieren oder zu verbieten | SELinux verwendet einen Satz von Regeln - in ihrer Gesamtheit als ''Policy'' bezeichnet - um Vorgänge zu autorisieren oder zu verbieten | ||
* Diese Regeln sind schwierig zu erstellen | * Diese Regeln sind schwierig zu erstellen | ||
* Glücklicherweise werden zwei Standardregelwerke (''targeted'' und ''strict'') bereitgestellt, die den Großteil der Konfigurierungsarbeit entbehrlich machen | * Glücklicherweise werden zwei Standardregelwerke (''targeted'' und ''strict'') bereitgestellt, die den Großteil der Konfigurierungsarbeit entbehrlich machen | ||
== Berechtigungen == | |||
[[File:selinux-context.png|mini|400px|Sicherheitskontexte und Unix-Nutzer]] | |||
Mit SELinux ist die Verwaltung der Berechtigungen grundsätzlich verschieden von traditionellen Unix-Systemen | Mit SELinux ist die Verwaltung der Berechtigungen grundsätzlich verschieden von traditionellen Unix-Systemen | ||
* Die Berechtigungen eines Prozesses hängen von seinem ''Sicherheitskontext'' ab | * Die Berechtigungen eines Prozesses hängen von seinem ''Sicherheitskontext'' ab | ||
| Zeile 20: | Zeile 23: | ||
* Und schließlich hängen die möglichen Übergänge zwischen den Rollen von der Identität ab | * Und schließlich hängen die möglichen Übergänge zwischen den Rollen von der Identität ab | ||
; Standard-Sicherheitskontext | |||
Nutzer bekommen während der Anmeldung einen Standard-Sicherheitskontext zugewiesen | |||
* Abhängigkeit von den Rollen | |||
* Dies bestimmt die geltende Domain und damit auch die Domain, der alle neuen Unterprozesse zugeordnet werden | |||
; Rollen und Domänen ändern | |||
Wenn man die geltende Rolle und die ihr zugeordnete Domain ändern will, muss man den Befehl | |||
newrole -r ''rolle_r'' -t ''domain_t'' | |||
aufrufen | |||
Normalerweise ist nur eine einzige Domain für eine bestimmte Rolle erlaubt, deshalb kann der Parameter -t häufig weggelassen werden | |||
* Dieser Befehl authentifiziert jemanden, indem er ihn auffordert, sein Passwort einzugeben | * Dieser Befehl authentifiziert jemanden, indem er ihn auffordert, sein Passwort einzugeben | ||
* Dies hindert Programme daran, selbstständig ihre Rollen zu ändern | * Dies hindert Programme daran, selbstständig ihre Rollen zu ändern | ||
* Derartige Änderungen sind nur möglich, wenn sie im SELinux-Regelwerk ausdrücklich erlaubt sind | * Derartige Änderungen sind nur möglich, wenn sie im SELinux-Regelwerk ausdrücklich erlaubt sind | ||
== Objekte == | |||
[[File:selinux-transitions.png|mini|300px|Übergänge zwischen Domains]] | |||
Offensichtlich gelten die Berechtigungen nicht für alle ''Objekte'' (Dateien, Verzeichnisse, Sockets, Geräte usw.) | Offensichtlich gelten die Berechtigungen nicht für alle ''Objekte'' (Dateien, Verzeichnisse, Sockets, Geräte usw.) | ||
* Sie können von Objekt zu Objekt unterschiedlich sein | * Sie können von Objekt zu Objekt unterschiedlich sein | ||
| Zeile 35: | Zeile 45: | ||
* Die Rechte einer Domain werden somit durch Sätze von Operationen ausgedrückt, die bei diesen Typen erlaubt sind oder nicht (und indirekt bei allen Objekten, die mit dem jeweiligen Typ gekennzeichnet sind) | * Die Rechte einer Domain werden somit durch Sätze von Operationen ausgedrückt, die bei diesen Typen erlaubt sind oder nicht (und indirekt bei allen Objekten, die mit dem jeweiligen Typ gekennzeichnet sind) | ||
; | ; Domains und Typen sind gleichwertig | ||
Intern ist eine Domain nur ein Typ, jedoch ein Typ, der nur für Prozesse gilt | Intern ist eine Domain nur ein Typ, jedoch ein Typ, der nur für Prozesse gilt | ||
* Daher tragen Domains das Suffix _t, genau wie Objekttypen | * Daher tragen Domains das Suffix _t, genau wie Objekttypen | ||
| Zeile 44: | Zeile 54: | ||
* Dieser automatische Vorgang des Domainwechsels ermöglicht es, jedem Programm nur die Berechtigungen zu gewähren, die es benötigt | * Dieser automatische Vorgang des Domainwechsels ermöglicht es, jedem Programm nur die Berechtigungen zu gewähren, die es benötigt | ||
* Dies ist ein wesentliches Prinzip von SELinux | * Dies ist ein wesentliches Prinzip von SELinux | ||
; | == Sicherheitskontext anzeigen == | ||
; Sicherheitskontext des Benutzers | |||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
id -Z | |||
</syntaxhighlight> | |||
<!-- output --> | |||
<syntaxhighlight lang="bash" highlight="" line> | |||
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 | |||
</syntaxhighlight> | |||
; Fehlermeldung | |||
<blockquote> | |||
''id: --context (-Z) funktioniert nur auf einem SELinux-fähigen Kernel'' | |||
* SELinux muss zunächst aktivieren | |||
* Das skript '''[[selinux-activate]]''' ausführen und den Computer neu starten | |||
</blockquote> | |||
; Sicherheitskontext eines Prozesses | |||
Um den Sicherheitskontext eines bestimmten Prozesses festzustellen, kann die Option Z des Befehls ps verwendet werden | Um den Sicherheitskontext eines bestimmten Prozesses festzustellen, kann die Option Z des Befehls ps verwendet werden | ||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
ps axZ | grep vstfpd | |||
</syntaxhighlight> | |||
<!-- output --> | |||
<syntaxhighlight lang="bash" highlight="" line> | |||
system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd | |||
</syntaxhighlight> | |||
Das erste Feld enthält durch Doppelpunkte getrennt die Identität, die Rolle, die Domain und die MCS-Stufe | Das erste Feld enthält durch Doppelpunkte getrennt die Identität, die Rolle, die Domain und die MCS-Stufe | ||
* Die MCS-Stufe (''Multi-Category Security'') ist ein Parameter, der beim Aufbau einer Regel zum Schutz der Vertraulichkeit eingreift, die den Zugriff auf Dateien in Abhängigkeit von ihrer Sensibilität regelt | * Die MCS-Stufe (''Multi-Category Security'') ist ein Parameter, der beim Aufbau einer Regel zum Schutz der Vertraulichkeit eingreift, die den Zugriff auf Dateien in Abhängigkeit von ihrer Sensibilität regelt | ||
; Typ anzeigen | |||
Um schließlich auch den Typ festzustellen, der einer Datei zugeordnet ist, kann man den Befehl ls -Z verwenden | Um schließlich auch den Typ festzustellen, der einer Datei zugeordnet ist, kann man den Befehl ls -Z verwenden | ||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
ls -Z test /usr/bin/ssh | |||
</syntaxhighlight> | |||
<!-- output --> | |||
<syntaxhighlight lang="bash" highlight="" line> | |||
unconfined_u:object_r:user_home_t:s0 test | |||
system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh | |||
</syntaxhighlight> | |||
; Hinweis | |||
<blockquote> | |||
* die Identität und die Rolle, die einer Datei zugewiesen sind, keine besondere Bedeutung haben (sie werden nie benutzt) | |||
* aus Gründen der Einheitlichkeit wird allen Objekten ein vollständiger Sicherheitskontext zugeordnet | |||
</blockquote> | |||
== | == Was ist SELinux? == | ||
[[SELinux]] bietet eine zusätzliche Ebene der Systemsicherheit | [[SELinux]] bietet eine zusätzliche Ebene der Systemsicherheit | ||
| Zeile 98: | Zeile 115: | ||
; Umfassende und fein abgestufte Sicherheitsrichtlinien | ; Umfassende und fein abgestufte Sicherheitsrichtlinien | ||
Standardmäßige Zugriffsrichtlinie | Standardmäßige Zugriffsrichtlinie | ||
* Discretionary Access Control (DAC) | |||
* basiert auf Benutzer-, Gruppen- und anderen Berechtigungen | |||
* | Ermöglicht es Systemadministratoren nicht | ||
* umfassende und fein abgestufte Sicherheitsrichtlinien zu erstellen | |||
* wie bestimmte Anwendungen darauf zu beschränken, Log-Dateien nur anzuzeigen, während anderen Anwendungen erlaubt wird, neue Daten an die Log-Dateien anzuhängen | |||
=== Mandatory Access Control === | |||
; SELinux implementiert [[Mandatory Access Control]] (MAC) | |||
Jeder Prozess und jede Systemressource verfügt über eine Sicherheitskennzeichnung ('''SELinux-Kontext''') | |||
Ein SELinux-Kontext, manchmal auch als „SELinux-Label“ bezeichnet, ist ein Identifikator, der die Details auf Systemebene abstrahiert und sich auf die Sicherheitseigenschaften der Entität konzentriert | |||
Dies ist eine konsistente Methode | |||
* zur Referenzierung von Objekten in der SELinux-Richtlinie | |||
* beseitigt auch jegliche Mehrdeutigkeit, die bei anderen Identifizierungsmethoden auftreten kann | |||
* beispielsweise kann eine Datei auf einem System, das Bind-Mounts verwendet, mehrere gültige Pfadnamen haben | |||
=== Kontexte === | |||
Die SELinux-Richtlinie verwendet diese Kontexte in einer Reihe von Regeln, die definieren, wie Prozesse miteinander und mit den verschiedenen Systemressourcen interagieren können | Die SELinux-Richtlinie verwendet diese Kontexte in einer Reihe von Regeln, die definieren, wie Prozesse miteinander und mit den verschiedenen Systemressourcen interagieren können | ||
* Standardmäßig erlaubt die Richtlinie keine Interaktion, es sei denn, eine Regel gewährt ausdrücklich Zugriff | * Standardmäßig erlaubt die Richtlinie keine Interaktion, es sei denn, eine Regel gewährt ausdrücklich Zugriff | ||
| Zeile 127: | Zeile 148: | ||
* Sicherheitsstufe | * Sicherheitsstufe | ||
=== Typinformationen === | |||
SELinux-Typinformationen sind für die SELinux-Richtlinie wohl am wichtigsten | |||
* da die gängigste Richtliniendevise, die die zulässigen Interaktionen zwischen Prozessen und Systemressourcen definiert, SELinux-Typen und nicht den vollständigen SELinux-Kontext verwendet | |||
; Richtlinienregel | ; SELinux-Typen enden in der Regel mit ''_t'' | ||
Es gibt | * Der Typname für den '''Webserver''' lautet beispielsweise '''httpd_t''' | ||
* Der Typkontext für '''Dateien und Verzeichnisse''' ist '''httpd_sys_content_t''' | |||
** die normalerweise unter /var/www/html/ zu finden sind, | |||
* Der Typkontext für Dateien und Verzeichnisse, die sich normalerweise in '''/tmp''' und '''/var/tmp/''' befinden, lautet '''tmp_t''' | |||
* Der Typkontext für Webserver-Ports lautet '''http_port_t''' | |||
=== Richtlinienregel === | |||
Es gibt eine Richtlinienregel, die Apache (dem als '''httpd_t''' ausgeführten Webserver-Prozess) den Zugriff auf Dateien und Verzeichnisse mit einem Kontext erlaubt, der normalerweise in '''/var/www/html/''' und anderen Webserver-Verzeichnissen ('''httpd_sys_content_t''') zu finden ist | |||
Da die Richtlinie keine Zulassungsregel für Dateien enthält, die sich normalerweise in '''/tmp''' und '''/var/tmp/''' befinden, ist der Zugriff nicht erlaubt | |||
Mit SELinux kann ein bösartiges Skript selbst dann nicht auf das Verzeichnis /tmp zugreifen, wenn Apache kompromittiert wurde und es Zugriff erlangt hat | |||
'''Abbildung 1.1''' | '''Abbildung 1.1''' | ||
=== Beispiel: HTTPD === | |||
SELinux erlaubt dem als httpd_t laufenden Apache-Prozess den Zugriff auf das Verzeichnis /var/www/html/ | SELinux '''erlaubt''' dem als '''httpd_t''' laufenden Apache-Prozess den Zugriff auf das Verzeichnis '''/var/www/html/''' | ||
* verweigert demselben Prozess den Zugriff auf das Verzeichnis '''/data/mysql/''' | |||
* da es keine Zulassungsregel für die Kontexte vom Typ '''httpd_t''' und '''mysqld_db_t''' gibt | |||
Andererseits kann der als '''mysqld_t''' ausgeführte MariaDB-Prozess auf das Verzeichnis '''/data/mysql/''' zugreifen | |||
* SELinux verweigert dem Prozess vom Typ '''mysqld_t''' korrekt den Zugriff auf das als '''httpd_sys_content_t''' gekennzeichnete Verzeichnis '''/var/www/html/''' | |||
== Architektur == | |||
; DAC und MAC | |||
DAC ist das klassische Unix-/Linux-Berechtigungsmodell. Der Zugriff auf eine Ressource wird im Wesentlichen über Eigentümer, Gruppe und Modusbits wie r, w und x gesteuert. | |||
MAC verfolgt einen anderen Ansatz. Hier entscheidet nicht der Eigentümer eines Objekts, sondern eine zentral definierte Sicherheitsrichtlinie. | |||
* Ein Zugriff ist nur dann erlaubt, wenn sowohl DAC als auch MAC ihn zulassen. | |||
* Ein Prozess darf also nicht allein deshalb auf eine Ressource zugreifen, weil die klassischen Dateirechte dies zulassen. | |||
; Linux Security Module | |||
SELinux ist ein Linux Security Module (LSM), das in den Linux-Kernel integriert ist | |||
Das SELinux-Subsystem im Kernel wird von einer Sicherheitsrichtlinie gesteuert, die vom Administrator kontrolliert und beim Systemstart geladen wird | |||
* Alle sicherheitsrelevanten Zugriffsvorgänge auf Kernel-Ebene im System werden von SELinux abgefangen und im Kontext der geladenen Sicherheitsrichtlinie geprüft | |||
* Wenn die geladene Richtlinie den Vorgang zulässt, wird er fortgesetzt | |||
* Andernfalls wird der Vorgang blockiert und der Prozess erhält eine Fehlermeldung | |||
; Access Vector Cache | |||
SELinux-Entscheidungen, wie das Zulassen oder Verweigern von Zugriff, werden zwischengespeichert | |||
* Dieser Cache wird als Access Vector Cache (AVC) bezeichnet | |||
* Durch die Verwendung dieser zwischengespeicherten Entscheidungen müssen die SELinux-Richtlinienregeln weniger häufig überprüft werden, was die Leistung erhöht | |||
; DAC-Regeln | |||
Beachten Sie, dass SELinux-Richtlinienregeln keine Wirkung haben, wenn DAC-Regeln den Zugriff zuvor verweigern | |||
== Linux-Kernel und Distributionen == | |||
; '''SELinux''' ist seit Linux-2.6.x im Kernel integriert | |||
* Die Linux-Distribution '''[[Fedora (Linux-Distribution)|Fedora]]''' (ein durch '''[[Red Hat]]''' gesponsertes Projekt) war die erste Distribution, die standardmäßig SELinux-Unterstützung mitliefert. | |||
* '''Fedora Core 3''' und '''Linux 4''' wurden als erste Distributionen mit voller SELinux-Unterstützung ausgeliefert | |||
* Mittlerweile ist es ebenfalls fester Bestandteil von '''[[AlmaLinux]]''', '''[[Rocky Linux]]''', '''[[Oracle Linux]]''' sowie '''[[CentOS]]''' und '''Hardened [[Gentoo Linux|Gentoo]]''' | |||
* Bei '''[[Ubuntu (Betriebssystem)|Ubuntu]]''', '''[[Debian]]''' und '''[[openSUSE]]''' bzw. '''[[SUSE Linux Enterprise Server|SLES]]''' sind die SELinux-Tools sowie stellenweise auch SELinux-Policies über die Paketverwaltung nachinstallierbar. | |||
; Ausgefeilte Policies | |||
Jedoch kann man nicht immer ausgefeilte Policies wie bei den RHEL-basierten Distributionen erwarten | |||
* Die Implementierung für '''[[Slackware]]''' ist noch in Arbeit | |||
; Android | |||
* Mit Einführung von [[Android (Betriebssystem)|Android]] 4.3 wurde auch offiziell der auf dem Linux-Kernel basierende Android-Kernel um SELinux erweitert. | |||
* Zuvor haben bereits Hersteller wie [[HTC Corporation|HTC]] und [[Samsung]] in ihren Smartphone-Modellen die Kernelerweiterung eingesetzt, um erweiterte Sicherheitsfunktionen zu implementieren. | |||
== Vorteile == | == Vorteile == | ||
=== Labels === | === Labels === | ||
Alle Prozesse und Dateien sind mit Labels versehen | Alle Prozesse und Dateien sind mit Labels versehen | ||
| Zeile 157: | Zeile 225: | ||
=== Fein abgestimmte Zugriffskontrolle === | === Fein abgestimmte Zugriffskontrolle === | ||
Über die traditionellen UNIX-Berechtigungen hinaus, die nach dem Ermessen des Benutzers gesteuert werden und auf Linux-Benutzer- und Gruppen-IDs basieren, basieren SELinux-Zugriffsentscheidungen auf allen verfügbaren Informationen, wie | '''Über die traditionellen UNIX-Berechtigungen hinaus''', die nach dem Ermessen des Benutzers gesteuert werden und auf Linux-Benutzer- und Gruppen-IDs basieren, basieren SELinux-Zugriffsentscheidungen auf allen verfügbaren Informationen, wie | ||
* einem '''SELinux-Benutzer''' | |||
* einer '''Rolle''' | |||
* einem '''Typ''' | |||
* einer '''Sicherheitsstufe''' (optional) | |||
Die SELinux-Richtlinie wird administrativ definiert und systemweit durchgesetzt | |||
* Verbesserte Abwehr von Angriffen zur Privilegieneskalation | * Verbesserte Abwehr von Angriffen zur Privilegieneskalation | ||
* Prozesse laufen in Domänen und sind daher voneinander getrennt | * Prozesse laufen in Domänen und sind daher voneinander getrennt | ||
* SELinux-Richtlinienregeln legen fest, wie Prozesse auf Dateien und andere Prozesse zugreifen | * SELinux-Richtlinienregeln legen fest, wie Prozesse auf Dateien und andere Prozesse zugreifen | ||
* Wenn ein Prozess kompromittiert wird, hat der Angreifer nur Zugriff auf die normalen Funktionen dieses Prozesses und auf Dateien, für die der Prozess konfiguriert | * Wenn ein Prozess kompromittiert wird, hat der Angreifer nur Zugriff auf die normalen Funktionen dieses Prozesses und auf Dateien, für die der Prozess konfiguriert wurde, darauf zuzugreifen | ||
wurde, darauf zuzugreifen | |||
; Beispiel | ; Beispiel | ||
Wenn | Wenn etwa der Apache-HTTP-Server kompromittiert wird | ||
* kann ein Angreifer diesen Prozess nicht nutzen, um Dateien in Benutzer-Home-Verzeichnissen zu lesen | |||
* es sei denn, eine spezifische SELinux-Richtlinienregel wurde hinzugefügt oder so konfiguriert, dass sie einen solchen Zugriff erlaubt | |||
SELinux kann eingesetzt werden, um die Vertraulichkeit und Integrität von Daten zu gewährleisten sowie Prozesse vor nicht vertrauenswürdigen Eingaben zu schützen | |||
; SELinux ist nicht | ; SELinux ist nicht | ||
| Zeile 173: | Zeile 249: | ||
* All-in-One-Sicherheitslösung | * All-in-One-Sicherheitslösung | ||
SELinux | ; SELinux soll bestehende Sicherheitslösungen zu ergänzen, nicht um sie zu ersetzen | ||
Auch bei der Verwendung von SELinux ist es wichtig, weiterhin bewährte Sicherheitspraktiken zu befolgen, wie z. B. | |||
* Aktualisierung von Software | |||
* Verwendung schwer zu erratender Passwörter | |||
* Einsatz von Firewalls | |||
== Beispiele == | == Beispiele == | ||
| Zeile 186: | Zeile 265: | ||
* In der SELinux-Richtlinie gibt es eine Reihe von eingeschränkten SELinux-Benutzern | * In der SELinux-Richtlinie gibt es eine Reihe von eingeschränkten SELinux-Benutzern | ||
* Linux-Benutzer können eingeschränkten SELinux-Benutzern zugeordnet werden, um die für diese geltenden Sicherheitsregeln und -mechanismen zu nutzen | * Linux-Benutzer können eingeschränkten SELinux-Benutzern zugeordnet werden, um die für diese geltenden Sicherheitsregeln und -mechanismen zu nutzen | ||
Wenn etwa ein Linux-Benutzer dem SELinux-Benutzer '''user_u''' zugeordnet wird, führt dies dazu, dass dieser Linux-Benutzer (sofern nicht anders konfiguriert) keine Set-User-ID-Anwendungen (setuid) wie '''sudo''' und '''su''' ausführen kann | |||
Weitere Informationen finden Sie in Abschnitt [[Linux/SELinux/03 Default Policy/Benutzer]] | |||
; Verbesserte Prozess- und Datentrennung | ; Verbesserte Prozess- und Datentrennung | ||
Prozesse laufen in ihren eigenen Domänen | Prozesse laufen in ihren eigenen Domänen | ||
* wodurch verhindert wird, dass Prozesse auf Dateien zugreifen, die von anderen Prozessen verwendet werden | |||
* und dass Prozesse auf andere Prozesse zugreifen | |||
Wenn SELinux ausgeführt wird, kann ein Angreifer – sofern nicht anders konfiguriert – keinen Samba-Server kompromittieren und diesen Samba-Server dann als Angriffsvektor nutzen, um auf Dateien zu lesen und zu schreiben, die von anderen Prozessen verwendet werden, wie z. B. MariaDB-Datenbanken | |||
; SELinux hilft dabei, den durch Konfigurationsfehler verursachten Schaden zu mindern | ; SELinux hilft dabei, den durch Konfigurationsfehler verursachten Schaden zu mindern | ||
Domain Name System (DNS)-Server replizieren häufig Informationen untereinander in einem sogenannten Zonentransfer | Domain Name System (DNS)-Server replizieren häufig Informationen untereinander in einem sogenannten Zonentransfer | ||
* Angreifer können Zonentransfers nutzen, um DNS-Server mit falschen Informationen zu aktualisieren | * Angreifer können Zonentransfers nutzen, um DNS-Server mit falschen Informationen zu aktualisieren | ||
<!-- | |||
; Beispiel BIND | |||
Wenn Berkeley Internet Name Domain (BIND) als DNS-Server unter Linux ausgeführt wird | |||
* verhindert die Standard-SELinux-Richtlinie – selbst wenn ein Administrator vergisst, einzuschränken, welche Server einen Zonentransfer durchführen dürfen –, dass Zonendateien] durch Zonentransfers, durch den BIND-Daemon named selbst oder durch andere Prozesse aktualisiert werden | |||
--> | |||
* | |||
== Zustände und Modi == | == Zustände und Modi == | ||
SELinux kann in einem von drei Modi ausgeführt werden | SELinux kann in einem von drei Modi ausgeführt werden | ||
{| class="wikitable options big" | |||
|- | |||
! Modus !! Beschreibung | |||
|- | |||
| deaktiviert || '''deaktivierten Modus''' (dringend abgeraten) | |||
* System verzichtet auf die Durchsetzung der SELinux-Richtlinie | |||
* und die Kennzeichnung persistenter Objekte wie Dateien | |||
* erschwert eine spätere Aktivierung von SELinux | |||
|- | |||
| permissiv || '''permissiven Modus''' SELinux ist aktiviert, verweigert jedoch keine Zugriffe | |||
* die geladene Sicherheitsrichtlinie werden beobachtet und protokolliet | |||
* Kennzeichnung von Objekten | |||
* Ausgabe von Zugriffsverweigerungseinträgen in den Protokollen | |||
* Der permissive Modus wird zwar nicht für Produktionssysteme empfohlen, kann jedoch bei der Entwicklung von SELinux-Richtlinien hilfreich sein | * Der permissive Modus wird zwar nicht für Produktionssysteme empfohlen, kann jedoch bei der Entwicklung von SELinux-Richtlinien hilfreich sein | ||
|- | |||
| durchgesetzt || '''Durchsetzungsmodus''' empfohlener Betriebsmodus | |||
* im Durchsetzungsmodus arbeitet SELinux normal | |||
* setzt die geladene Sicherheitsrichtlinie im gesamten System durch | |||
|} | |||
<noinclude> | |||
== Überblick == | |||
{| class="wikitable options big col1center" | |||
|- | |||
! | |||
! Unix !! Beschreibung | |||
|- | |||
| 01 | |||
| [[Linux/SELinux/01 Grundlagen|Einführung]] || | |||
|- | |||
| 02 | |||
| [[Linux/SELinux/02 Kontext|Kontext]] || | |||
|- | |||
| 03 | |||
| [[Linux/SELinux/03 Default Policy|Default Policy]] || | |||
|- | |||
| 04 | |||
| [[Linux/SELinux/04 Arbeiten mit SELinux|Arbeiten mit SELinux]] || | |||
|- | |||
| 05 | |||
| [[Linux/SELinux/05_SEPolicy|SEPolicy Suite]] || | |||
|- | |||
| 06 | |||
| [[Linux/SELinux/06 Benutzer|Benutzer einschränken]] || | |||
|- | |||
| 07 | |||
| [[Linux/SELinux/07 Sandbox|Sandbox]] || | |||
|- | |||
| 08 | |||
| [[Linux/SELinux/08 Virtualisierung|Virtualisierung]] || | |||
|- | |||
| 09 | |||
| [[Linux/SELinux/09 Container|Containers]] || | |||
|- | |||
| 10 | |||
| [[Linux/SELinux/10 Systemd|SELinux und Systemd]] || | |||
|- | |||
| 11 | |||
| [[Linux/SELinux/11 Fehlerbehebung|Fehlerbehebung]] || | |||
|- | |||
| 12 | |||
| [[Linux/SELinux/12 Automatisierung|Automatisierung]] || | |||
|} | |||
== Anhang == | == Anhang == | ||
| Zeile 268: | Zeile 375: | ||
==== Projekt ==== | ==== Projekt ==== | ||
==== Weblinks ==== | ==== Weblinks ==== | ||
# https://de.wikipedia.org/wiki/SELinux | |||
# https://debian-handbook.info/browse/de-DE/stable/sect.selinux.html | |||
# https://github.com/SELinuxProject/ | |||
<!-- | |||
# Red Hat Identity Management (IdM) | # Red Hat Identity Management (IdM) | ||
#* bietet eine zentralisierte Lösung zur Definition von SELinux-Benutzerzuordnungen | #* bietet eine zentralisierte Lösung zur Definition von SELinux-Benutzerzuordnungen | ||
| Zeile 278: | Zeile 390: | ||
# SELinux-Wiki-FAQ | # SELinux-Wiki-FAQ | ||
{{DEFAULTSORT:new}} | {{DEFAULTSORT:new}} | ||
{{DISPLAYTITLE:new}} | {{DISPLAYTITLE:new}} | ||
--> | --> | ||
---- | |||
{{Navigation|SELinux|Linux/SELinux/02 Installation}} | |||
[[Kategorie:Linux/SELinux]] | [[Kategorie:Linux/SELinux]] | ||
[[Kategorie:Linux/SELinux/01]] | [[Kategorie:Linux/SELinux/01]] | ||
</noinclude> | </noinclude> | ||
Aktuelle Version vom 31. März 2026, 13:32 Uhr
Linux/SELinux/01 Grundlagen - Security-Enhanced Linux
Beschreibung
SELinux (Security Enhanced Linux) ist ein System mit
- Mandatory Access Control (MAC)
- baut auf der LSM-Schnittstelle (Linux Security Modules) des Linux-Kernels auf
In der Praxis befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen
Regeln
SELinux verwendet einen Satz von Regeln - in ihrer Gesamtheit als Policy bezeichnet - um Vorgänge zu autorisieren oder zu verbieten
- Diese Regeln sind schwierig zu erstellen
- Glücklicherweise werden zwei Standardregelwerke (targeted und strict) bereitgestellt, die den Großteil der Konfigurierungsarbeit entbehrlich machen
Berechtigungen

Mit SELinux ist die Verwaltung der Berechtigungen grundsätzlich verschieden von traditionellen Unix-Systemen
- Die Berechtigungen eines Prozesses hängen von seinem Sicherheitskontext ab
- Der Kontext wird von der Identität des Benutzers bestimmt, der den Prozess gestartet hat, sowie von der Rolle und der Domain, die dem Benutzer zu dieser Zeit übertragen waren
- Die Berechtigungen hängen tatsächlich von der Domain ab, aber die Übergänge zwischen den Domains werden von den Rollen kontrolliert
- Und schließlich hängen die möglichen Übergänge zwischen den Rollen von der Identität ab
- Standard-Sicherheitskontext
Nutzer bekommen während der Anmeldung einen Standard-Sicherheitskontext zugewiesen
- Abhängigkeit von den Rollen
- Dies bestimmt die geltende Domain und damit auch die Domain, der alle neuen Unterprozesse zugeordnet werden
- Rollen und Domänen ändern
Wenn man die geltende Rolle und die ihr zugeordnete Domain ändern will, muss man den Befehl
newrole -r rolle_r -t domain_t
aufrufen
Normalerweise ist nur eine einzige Domain für eine bestimmte Rolle erlaubt, deshalb kann der Parameter -t häufig weggelassen werden
- Dieser Befehl authentifiziert jemanden, indem er ihn auffordert, sein Passwort einzugeben
- Dies hindert Programme daran, selbstständig ihre Rollen zu ändern
- Derartige Änderungen sind nur möglich, wenn sie im SELinux-Regelwerk ausdrücklich erlaubt sind
Objekte

Offensichtlich gelten die Berechtigungen nicht für alle Objekte (Dateien, Verzeichnisse, Sockets, Geräte usw.)
- Sie können von Objekt zu Objekt unterschiedlich sein
- Um dies zu erreichen, ist jedes Objekt einem Typ zugeordnet (dies wird als Kennzeichnung bezeichnet)
- Die Rechte einer Domain werden somit durch Sätze von Operationen ausgedrückt, die bei diesen Typen erlaubt sind oder nicht (und indirekt bei allen Objekten, die mit dem jeweiligen Typ gekennzeichnet sind)
- Domains und Typen sind gleichwertig
Intern ist eine Domain nur ein Typ, jedoch ein Typ, der nur für Prozesse gilt
- Daher tragen Domains das Suffix _t, genau wie Objekttypen
- Domain
Standardmäßig übernimmt ein Programm die Domain des Nutzers, der es gestartet hat, aber die normalen SELinux-Regeln erwarten, dass viele wichtige Programme in speziell für sie vorgesehenen Domains laufen
- Um dies zu erreichen, werden diese ausführbaren Dateien mit einem fest zugeordneten Typ gekennzeichnet (zum Beispiel wird ssh mit ssh_exec_t gekennzeichnet und wenn das Programm startet, wechselt es selbstständig in die Domain ssh_t)
- Dieser automatische Vorgang des Domainwechsels ermöglicht es, jedem Programm nur die Berechtigungen zu gewähren, die es benötigt
- Dies ist ein wesentliches Prinzip von SELinux
Sicherheitskontext anzeigen
- Sicherheitskontext des Benutzers
id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
- Fehlermeldung
id: --context (-Z) funktioniert nur auf einem SELinux-fähigen Kernel
- SELinux muss zunächst aktivieren
- Das skript selinux-activate ausführen und den Computer neu starten
- Sicherheitskontext eines Prozesses
Um den Sicherheitskontext eines bestimmten Prozesses festzustellen, kann die Option Z des Befehls ps verwendet werden
ps axZ | grep vstfpd
system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd
Das erste Feld enthält durch Doppelpunkte getrennt die Identität, die Rolle, die Domain und die MCS-Stufe
- Die MCS-Stufe (Multi-Category Security) ist ein Parameter, der beim Aufbau einer Regel zum Schutz der Vertraulichkeit eingreift, die den Zugriff auf Dateien in Abhängigkeit von ihrer Sensibilität regelt
- Typ anzeigen
Um schließlich auch den Typ festzustellen, der einer Datei zugeordnet ist, kann man den Befehl ls -Z verwenden
ls -Z test /usr/bin/ssh
unconfined_u:object_r:user_home_t:s0 test
system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh
- Hinweis
- die Identität und die Rolle, die einer Datei zugewiesen sind, keine besondere Bedeutung haben (sie werden nie benutzt)
- aus Gründen der Einheitlichkeit wird allen Objekten ein vollständiger Sicherheitskontext zugeordnet
Was ist SELinux?
SELinux bietet eine zusätzliche Ebene der Systemsicherheit
- SELinux beantwortet im Wesentlichen die Frage
Darf Subjekt die Aktion an Objekt ausführen?
- Beispiel
- Darf ein Webserver auf Dateien in den Home-Verzeichnissen der Benutzer zugreifen?
- Umfassende und fein abgestufte Sicherheitsrichtlinien
Standardmäßige Zugriffsrichtlinie
- Discretionary Access Control (DAC)
- basiert auf Benutzer-, Gruppen- und anderen Berechtigungen
Ermöglicht es Systemadministratoren nicht
- umfassende und fein abgestufte Sicherheitsrichtlinien zu erstellen
- wie bestimmte Anwendungen darauf zu beschränken, Log-Dateien nur anzuzeigen, während anderen Anwendungen erlaubt wird, neue Daten an die Log-Dateien anzuhängen
Mandatory Access Control
- SELinux implementiert Mandatory Access Control (MAC)
Jeder Prozess und jede Systemressource verfügt über eine Sicherheitskennzeichnung (SELinux-Kontext)
Ein SELinux-Kontext, manchmal auch als „SELinux-Label“ bezeichnet, ist ein Identifikator, der die Details auf Systemebene abstrahiert und sich auf die Sicherheitseigenschaften der Entität konzentriert
Dies ist eine konsistente Methode
- zur Referenzierung von Objekten in der SELinux-Richtlinie
- beseitigt auch jegliche Mehrdeutigkeit, die bei anderen Identifizierungsmethoden auftreten kann
- beispielsweise kann eine Datei auf einem System, das Bind-Mounts verwendet, mehrere gültige Pfadnamen haben
Kontexte
Die SELinux-Richtlinie verwendet diese Kontexte in einer Reihe von Regeln, die definieren, wie Prozesse miteinander und mit den verschiedenen Systemressourcen interagieren können
- Standardmäßig erlaubt die Richtlinie keine Interaktion, es sei denn, eine Regel gewährt ausdrücklich Zugriff
- Hinweis
- Es ist wichtig zu beachten, dass SELinux-Richtlinienregeln nach den DAC-Regeln überprüft werden
- SELinux-Richtlinienregeln werden nicht angewendet, wenn DAC-Regeln den Zugriff zuerst verweigern, was bedeutet, dass keine SELinux-Verweigerung protokolliert wird, wenn die herkömmlichen DAC-Regeln den Zugriff verhindern
- Felder
SELinux-Kontexte bestehen aus mehreren Feldern
- Benutzer
- Rolle
- Typ
- Sicherheitsstufe
Typinformationen
SELinux-Typinformationen sind für die SELinux-Richtlinie wohl am wichtigsten
- da die gängigste Richtliniendevise, die die zulässigen Interaktionen zwischen Prozessen und Systemressourcen definiert, SELinux-Typen und nicht den vollständigen SELinux-Kontext verwendet
- SELinux-Typen enden in der Regel mit _t
- Der Typname für den Webserver lautet beispielsweise httpd_t
- Der Typkontext für Dateien und Verzeichnisse ist httpd_sys_content_t
- die normalerweise unter /var/www/html/ zu finden sind,
- Der Typkontext für Dateien und Verzeichnisse, die sich normalerweise in /tmp und /var/tmp/ befinden, lautet tmp_t
- Der Typkontext für Webserver-Ports lautet http_port_t
Richtlinienregel
Es gibt eine Richtlinienregel, die Apache (dem als httpd_t ausgeführten Webserver-Prozess) den Zugriff auf Dateien und Verzeichnisse mit einem Kontext erlaubt, der normalerweise in /var/www/html/ und anderen Webserver-Verzeichnissen (httpd_sys_content_t) zu finden ist
Da die Richtlinie keine Zulassungsregel für Dateien enthält, die sich normalerweise in /tmp und /var/tmp/ befinden, ist der Zugriff nicht erlaubt
Mit SELinux kann ein bösartiges Skript selbst dann nicht auf das Verzeichnis /tmp zugreifen, wenn Apache kompromittiert wurde und es Zugriff erlangt hat
Abbildung 1.1
Beispiel: HTTPD
SELinux erlaubt dem als httpd_t laufenden Apache-Prozess den Zugriff auf das Verzeichnis /var/www/html/
- verweigert demselben Prozess den Zugriff auf das Verzeichnis /data/mysql/
- da es keine Zulassungsregel für die Kontexte vom Typ httpd_t und mysqld_db_t gibt
Andererseits kann der als mysqld_t ausgeführte MariaDB-Prozess auf das Verzeichnis /data/mysql/ zugreifen
- SELinux verweigert dem Prozess vom Typ mysqld_t korrekt den Zugriff auf das als httpd_sys_content_t gekennzeichnete Verzeichnis /var/www/html/
Architektur
- DAC und MAC
DAC ist das klassische Unix-/Linux-Berechtigungsmodell. Der Zugriff auf eine Ressource wird im Wesentlichen über Eigentümer, Gruppe und Modusbits wie r, w und x gesteuert.
MAC verfolgt einen anderen Ansatz. Hier entscheidet nicht der Eigentümer eines Objekts, sondern eine zentral definierte Sicherheitsrichtlinie.
- Ein Zugriff ist nur dann erlaubt, wenn sowohl DAC als auch MAC ihn zulassen.
- Ein Prozess darf also nicht allein deshalb auf eine Ressource zugreifen, weil die klassischen Dateirechte dies zulassen.
- Linux Security Module
SELinux ist ein Linux Security Module (LSM), das in den Linux-Kernel integriert ist
Das SELinux-Subsystem im Kernel wird von einer Sicherheitsrichtlinie gesteuert, die vom Administrator kontrolliert und beim Systemstart geladen wird
- Alle sicherheitsrelevanten Zugriffsvorgänge auf Kernel-Ebene im System werden von SELinux abgefangen und im Kontext der geladenen Sicherheitsrichtlinie geprüft
- Wenn die geladene Richtlinie den Vorgang zulässt, wird er fortgesetzt
- Andernfalls wird der Vorgang blockiert und der Prozess erhält eine Fehlermeldung
- Access Vector Cache
SELinux-Entscheidungen, wie das Zulassen oder Verweigern von Zugriff, werden zwischengespeichert
- Dieser Cache wird als Access Vector Cache (AVC) bezeichnet
- Durch die Verwendung dieser zwischengespeicherten Entscheidungen müssen die SELinux-Richtlinienregeln weniger häufig überprüft werden, was die Leistung erhöht
- DAC-Regeln
Beachten Sie, dass SELinux-Richtlinienregeln keine Wirkung haben, wenn DAC-Regeln den Zugriff zuvor verweigern
Linux-Kernel und Distributionen
- SELinux ist seit Linux-2.6.x im Kernel integriert
- Die Linux-Distribution Fedora (ein durch Red Hat gesponsertes Projekt) war die erste Distribution, die standardmäßig SELinux-Unterstützung mitliefert.
- Fedora Core 3 und Linux 4 wurden als erste Distributionen mit voller SELinux-Unterstützung ausgeliefert
- Mittlerweile ist es ebenfalls fester Bestandteil von AlmaLinux, Rocky Linux, Oracle Linux sowie CentOS und Hardened Gentoo
- Bei Ubuntu, Debian und openSUSE bzw. SLES sind die SELinux-Tools sowie stellenweise auch SELinux-Policies über die Paketverwaltung nachinstallierbar.
- Ausgefeilte Policies
Jedoch kann man nicht immer ausgefeilte Policies wie bei den RHEL-basierten Distributionen erwarten
- Die Implementierung für Slackware ist noch in Arbeit
- Android
- Mit Einführung von Android 4.3 wurde auch offiziell der auf dem Linux-Kernel basierende Android-Kernel um SELinux erweitert.
- Zuvor haben bereits Hersteller wie HTC und Samsung in ihren Smartphone-Modellen die Kernelerweiterung eingesetzt, um erweiterte Sicherheitsfunktionen zu implementieren.
Vorteile
Labels
Alle Prozesse und Dateien sind mit Labels versehen
Richtlinienregeln
SELinux-Richtlinienregeln definieren, wie Prozesse mit Dateien interagieren sowie wie Prozesse miteinander interagieren
- Zugriff ist nur dann erlaubt, wenn eine SELinux-Richtlinienregel existiert, die dies ausdrücklich erlaubt
Fein abgestimmte Zugriffskontrolle
Über die traditionellen UNIX-Berechtigungen hinaus, die nach dem Ermessen des Benutzers gesteuert werden und auf Linux-Benutzer- und Gruppen-IDs basieren, basieren SELinux-Zugriffsentscheidungen auf allen verfügbaren Informationen, wie
- einem SELinux-Benutzer
- einer Rolle
- einem Typ
- einer Sicherheitsstufe (optional)
Die SELinux-Richtlinie wird administrativ definiert und systemweit durchgesetzt
- Verbesserte Abwehr von Angriffen zur Privilegieneskalation
- Prozesse laufen in Domänen und sind daher voneinander getrennt
- SELinux-Richtlinienregeln legen fest, wie Prozesse auf Dateien und andere Prozesse zugreifen
- Wenn ein Prozess kompromittiert wird, hat der Angreifer nur Zugriff auf die normalen Funktionen dieses Prozesses und auf Dateien, für die der Prozess konfiguriert wurde, darauf zuzugreifen
- Beispiel
Wenn etwa der Apache-HTTP-Server kompromittiert wird
- kann ein Angreifer diesen Prozess nicht nutzen, um Dateien in Benutzer-Home-Verzeichnissen zu lesen
- es sei denn, eine spezifische SELinux-Richtlinienregel wurde hinzugefügt oder so konfiguriert, dass sie einen solchen Zugriff erlaubt
SELinux kann eingesetzt werden, um die Vertraulichkeit und Integrität von Daten zu gewährleisten sowie Prozesse vor nicht vertrauenswürdigen Eingaben zu schützen
- SELinux ist nicht
- Antivirensoftware
- Ersatz für Passwörter, Firewalls und andere Sicherheitssysteme
- All-in-One-Sicherheitslösung
- SELinux soll bestehende Sicherheitslösungen zu ergänzen, nicht um sie zu ersetzen
Auch bei der Verwendung von SELinux ist es wichtig, weiterhin bewährte Sicherheitspraktiken zu befolgen, wie z. B.
- Aktualisierung von Software
- Verwendung schwer zu erratender Passwörter
- Einsatz von Firewalls
Beispiele
Beispiele für die Erhöhung der Sicherheit durch SELinux
- Standardaktion „verweigern“
Wenn keine SELinux-Richtlinienregel existiert, die den Zugriff erlaubt, beispielsweise für einen Prozess, der eine Datei öffnet, wird der Zugriff verweigert
- Benutzer einschränken
SELinux kann Linux-Benutzer einschränken
- In der SELinux-Richtlinie gibt es eine Reihe von eingeschränkten SELinux-Benutzern
- Linux-Benutzer können eingeschränkten SELinux-Benutzern zugeordnet werden, um die für diese geltenden Sicherheitsregeln und -mechanismen zu nutzen
Wenn etwa ein Linux-Benutzer dem SELinux-Benutzer user_u zugeordnet wird, führt dies dazu, dass dieser Linux-Benutzer (sofern nicht anders konfiguriert) keine Set-User-ID-Anwendungen (setuid) wie sudo und su ausführen kann
Weitere Informationen finden Sie in Abschnitt Linux/SELinux/03 Default Policy/Benutzer
- Verbesserte Prozess- und Datentrennung
Prozesse laufen in ihren eigenen Domänen
- wodurch verhindert wird, dass Prozesse auf Dateien zugreifen, die von anderen Prozessen verwendet werden
- und dass Prozesse auf andere Prozesse zugreifen
Wenn SELinux ausgeführt wird, kann ein Angreifer – sofern nicht anders konfiguriert – keinen Samba-Server kompromittieren und diesen Samba-Server dann als Angriffsvektor nutzen, um auf Dateien zu lesen und zu schreiben, die von anderen Prozessen verwendet werden, wie z. B. MariaDB-Datenbanken
- SELinux hilft dabei, den durch Konfigurationsfehler verursachten Schaden zu mindern
Domain Name System (DNS)-Server replizieren häufig Informationen untereinander in einem sogenannten Zonentransfer
- Angreifer können Zonentransfers nutzen, um DNS-Server mit falschen Informationen zu aktualisieren
Zustände und Modi
SELinux kann in einem von drei Modi ausgeführt werden
| Modus | Beschreibung |
|---|---|
| deaktiviert | deaktivierten Modus (dringend abgeraten)
|
| permissiv | permissiven Modus SELinux ist aktiviert, verweigert jedoch keine Zugriffe
|
| durchgesetzt | Durchsetzungsmodus empfohlener Betriebsmodus
|
Überblick
| Unix | Beschreibung | |
|---|---|---|
| 01 | Einführung | |
| 02 | Kontext | |
| 03 | Default Policy | |
| 04 | Arbeiten mit SELinux | |
| 05 | SEPolicy Suite | |
| 06 | Benutzer einschränken | |
| 07 | Sandbox | |
| 08 | Virtualisierung | |
| 09 | Containers | |
| 10 | SELinux und Systemd | |
| 11 | Fehlerbehebung | |
| 12 | Automatisierung |
Anhang
Siehe auch
Dokumentation
Links
Projekt
Weblinks
- https://de.wikipedia.org/wiki/SELinux
- https://debian-handbook.info/browse/de-DE/stable/sect.selinux.html
- https://github.com/SELinuxProject/