https://wiki.ixheim.de/index.php?action=history&feed=atom&title=SELinux_Grundlagen 2026-04-15T04:51:25Z Versionsgeschichte dieser Seite in Xinux Wiki MediaWiki 1.35.1 https://wiki.ixheim.de/index.php?title=SELinux_Grundlagen&diff=67823&oldid=prev 2026-03-27T06:26:19Z

<p>Die Seite wurde neu angelegt: „== Die Ausgangslage: Das Problem (DAC) == * Klassische Linux-Sicherheit basiert auf Discretionary Access Control (DAC). * Zugriffsrechte (rwx) hängen allein v…“</p> <p><b>Neue Seite</b></p><div>== Die Ausgangslage: Das Problem (DAC) ==<br /> * Klassische Linux-Sicherheit basiert auf Discretionary Access Control (DAC).<br /> * Zugriffsrechte (rwx) hängen allein von Benutzer- und Gruppen-IDs ab.<br /> * Der Besitzer einer Datei entscheidet über die Freigabe seiner Daten.<br /> * Ein Prozess erbt alle Rechte des Benutzers, der ihn startet.<br /> * Erlangt ein Angreifer Root-Rechte, kann er alle DAC-Schranken umgehen.<br /> * Das gesamte System ist bei einer Kompromittierung eines Root-Dienstes offen.<br /> <br /> == Die Lösung: Mandatory Access Control (MAC) ==<br /> * SELinux erweitert den Kernel um Mandatory Access Control (MAC).<br /> * Die Zugriffskontrolle liegt fest in der Hand des Systems (Kernel-Policy).<br /> * Kein Benutzer – auch nicht Root – kann die zentralen Regeln eigenmächtig ändern.<br /> * Sicherheit wird nicht mehr über Identitäten (UID), sondern über Zwecke (Rollen) definiert.<br /> * Das Ziel ist die Isolation von Prozessen in eng gefassten &quot;Käfigen&quot; (Sandboxing).<br /> <br /> == Das Herzstück: Das Labeling-System ==<br /> * Jedes Element im System benötigt eine eindeutige Kennzeichnung (Label).<br /> * Subjekte sind aktive Akteure, meist laufende Prozesse.<br /> * Objekte sind passive Ressourcen wie Dateien, Verzeichnisse, Ports oder Sockets.<br /> * Der Sicherheitskontext (Label) verknüpft Subjekte und Objekte mit der Policy.<br /> * Ohne gültiges Label ist eine Ressource für das System unsichtbar oder gesperrt.<br /> <br /> <br /> <br /> == Die Struktur des Sicherheitskontexts ==<br /> * Ein Kontext besteht aus vier festen Attributen: User : Rolle : Typ : Ebene.<br /> * system_u (User): Die SELinux-Identität, unabhängig vom Linux-Nutzer.<br /> * object_r (Rolle): Definiert, welche Typen ein Subjekt annehmen darf.<br /> * httpd_sys_content_t (Typ): Das wichtigste Feld für die tägliche Administration.<br /> * s0 (Ebene): Bestimmt die Sicherheitsstufe (MLS) oder Kategorie (MCS).<br /> <br /> == Das Prinzip des Type Enforcement (TE) ==<br /> * Der Zugriff wird primär über den &quot;Typ&quot; (Type) des Labels gesteuert.<br /> * Die Policy definiert explizit: &quot;Typ A darf auf Typ B mit Aktion C zugreifen&quot;.<br /> * Alles, was nicht ausdrücklich in der Policy erlaubt ist, bleibt verboten (Default Deny).<br /> * Ein Webserver-Prozess darf so nur Web-Dateien lesen, aber keine System-Passwörter.<br /> * Selbst bei einer Kompromittierung bleibt der Schaden auf den erlaubten Typ begrenzt.<br /> <br /> <br /> <br /> == Der Entscheidungsprozess im Kernel ==<br /> * Ein Prozess stellt eine Anfrage an eine Ressource (z. B. Datei öffnen).<br /> * Schritt 1: Der Kernel prüft die Standard-Berechtigungen (DAC).<br /> * Schritt 2: Wenn DAC zustimmt, erfolgt die Prüfung durch die SELinux-Policy.<br /> * Schritt 3: Der Access Vector Cache (AVC) beschleunigt die Abfrage durch Pufferung.<br /> * Schritt 4: Nur bei positivem Bescheid beider Instanzen wird der Zugriff gewährt.<br /> * Verstöße werden sofort blockiert und im Audit-System (/var/log/audit/audit.log) vermerkt.<br /> <br /> == Zusammenfassender Nutzen ==<br /> * Effektive Schadensbegrenzung bei erfolgreichen Angriffen auf Netzwerkdienste.<br /> * Verhindern von Privilegieneskalation über Sicherheitslücken in Programmen.<br /> * Schutz der Systemintegrität vor unbefugten Änderungen durch Dienste.<br /> * Feingranulare Kontrolle über Systemressourcen weit über rwx hinaus.</div>

Thomas.will