SELinux Grundlagen

Die Ausgangslage: Das Problem (DAC)

• Klassische Linux-Sicherheit basiert auf Discretionary Access Control (DAC).
• Zugriffsrechte (rwx) hängen allein von Benutzer- und Gruppen-IDs ab.
• Der Besitzer einer Datei entscheidet über die Freigabe seiner Daten.
• Ein Prozess erbt alle Rechte des Benutzers, der ihn startet.
• Erlangt ein Angreifer Root-Rechte, kann er alle DAC-Schranken umgehen.
• Das gesamte System ist bei einer Kompromittierung eines Root-Dienstes offen.

Die Lösung: Mandatory Access Control (MAC)

• SELinux erweitert den Kernel um Mandatory Access Control (MAC).
• Die Zugriffskontrolle liegt fest in der Hand des Systems (Kernel-Policy).
• Kein Benutzer – auch nicht Root – kann die zentralen Regeln eigenmächtig ändern.
• Sicherheit wird nicht mehr über Identitäten (UID), sondern über Zwecke (Rollen) definiert.
• Das Ziel ist die Isolation von Prozessen in eng gefassten "Käfigen" (Sandboxing).

Das Herzstück: Das Labeling-System

• Jedes Element im System benötigt eine eindeutige Kennzeichnung (Label).
• Subjekte sind aktive Akteure, meist laufende Prozesse.
• Objekte sind passive Ressourcen wie Dateien, Verzeichnisse, Ports oder Sockets.
• Der Sicherheitskontext (Label) verknüpft Subjekte und Objekte mit der Policy.
• Ohne gültiges Label ist eine Ressource für das System unsichtbar oder gesperrt.

Die Struktur des Sicherheitskontexts

• Ein Kontext besteht aus vier festen Attributen: User : Rolle : Typ : Ebene.
• system_u (User): Die SELinux-Identität, unabhängig vom Linux-Nutzer.
• object_r (Rolle): Definiert, welche Typen ein Subjekt annehmen darf.
• httpd_sys_content_t (Typ): Das wichtigste Feld für die tägliche Administration.
• s0 (Ebene): Bestimmt die Sicherheitsstufe (MLS) oder Kategorie (MCS).

Das Prinzip des Type Enforcement (TE)

• Der Zugriff wird primär über den "Typ" (Type) des Labels gesteuert.
• Die Policy definiert explizit: "Typ A darf auf Typ B mit Aktion C zugreifen".
• Alles, was nicht ausdrücklich in der Policy erlaubt ist, bleibt verboten (Default Deny).
• Ein Webserver-Prozess darf so nur Web-Dateien lesen, aber keine System-Passwörter.
• Selbst bei einer Kompromittierung bleibt der Schaden auf den erlaubten Typ begrenzt.

Der Entscheidungsprozess im Kernel

• Ein Prozess stellt eine Anfrage an eine Ressource (z. B. Datei öffnen).
• Schritt 1: Der Kernel prüft die Standard-Berechtigungen (DAC).
• Schritt 2: Wenn DAC zustimmt, erfolgt die Prüfung durch die SELinux-Policy.
• Schritt 3: Der Access Vector Cache (AVC) beschleunigt die Abfrage durch Pufferung.
• Schritt 4: Nur bei positivem Bescheid beider Instanzen wird der Zugriff gewährt.
• Verstöße werden sofort blockiert und im Audit-System (/var/log/audit/audit.log) vermerkt.

Zusammenfassender Nutzen

• Effektive Schadensbegrenzung bei erfolgreichen Angriffen auf Netzwerkdienste.
• Verhindern von Privilegieneskalation über Sicherheitslücken in Programmen.
• Schutz der Systemintegrität vor unbefugten Änderungen durch Dienste.
• Feingranulare Kontrolle über Systemressourcen weit über rwx hinaus.