Linux/SELinux/01 Grundlagen

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

die auf Benutzer-, Gruppen- und anderen Berechtigungen basiert
Discretionary Access Control (DAC)

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

SELinux implementiert Mandatory Access Control (MAC)

Jeder Prozess und jede Systemressource verfügt über eine spezielle Sicherheitskennzeichnung, die als „SELinux-Kontext“ bezeichnet wird
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 bietet nicht nur eine konsistente Methode zur Referenzierung von Objekten in der SELinux-Richtlinie, sondern 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 etwa 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 z. B. einem SELinux-Benutzer, einer Rolle, einem Typ und optional einer Sicherheitsstufe

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 beispielsweise 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 wurde entwickelt, um 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. die Aktualisierung von Software, die Verwendung schwer zu erratender Passwörter oder den 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 beispielsweise 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 3.3, „Eingeschränkte und uneingeschränkte 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 beispielsweise 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
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 [1] durch Zonentransfers, durch den BIND-Daemon named selbst oder durch andere Prozesse aktualisiert werden

Hintergrundinformationen

zu SELinux sowie Informationen zu verschiedenen Exploits, die SELinux verhindert hat, finden Sie im Artikel auf NetworkWorld.com: „A seatbelt for server software: SELinux blocks real-world exploits“[2]

Zustände und Modi

SELinux kann in einem von drei Modi ausgeführt werden

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
durchgesetzt	Durchsetzungsmodus empfohlener Betriebsmodus im Durchsetzungsmodus arbeitet SELinux normal setzt die geladene Sicherheitsrichtlinie im gesamten System durch

Ü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

Linux/SELinux/01 Grundlagen/Quickstart

Dokumentation

Links

Projekt

Weblinks

← Zurück

Weiter →