Änderung der Bereitstellung des RHEL-Quellcodes durch Red Hat
- Im Juni 2023 traf Red Hat die umstrittene Entscheidung, die Art der Bereitstellung des Quellcodes hinter Red Hat Enterprise Linux (RHEL) zu ändern
- Diese Entscheidung warf viele Fragen zur künftigen Überlebensfähigkeit von Downstream-Rebuilds von RHEL wie Rocky Linux, AlmaLinux und Oracle Linux auf
- Die einzelnen Distributionen veröffentlichten daraufhin Erklärungen, um die Community zu beruhigen
- In vielen Open-Source-Communities wurde die Entscheidung von Red Hat als Einfluss eines gierigen Konzerns interpretiert
- Menschen suchen Zuflucht, indem sie sagen, sie wechselten zu Debian oder seien bereits gewechselt
Die Bedeutung und Schwierigkeit von Sicherheit
- Sicherheit ist schwierig, langweilig, unerquicklich und erfordert viel Aufwand, wenn man sie richtig umsetzen will
- Debian unternimmt nicht genügend Anstrengungen, um seine Nutzer zu schützen
Red Hats Einführung von SELinux und Bereitstellung von Standardrichtlinien
- Red Hat hat den Einsatz von SELinux schon vor langer Zeit angenommen und ist dabei über das bloße Aktivieren der Funktion im Kernel hinausgegangen
- Das Unternehmen übernahm die mühsame Arbeit, Standard-SELinux-Richtlinien für die Distribution zu erstellen
- Diese Richtlinien sind in RHEL standardmäßig aktiviert und helfen dabei, die am häufigsten eingesetzten Daemons zu schützen, die von den verschiedenen Daemons und Servern in einer RHEL-Installation standardmäßig ausgeführt werden
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH und weitere werden alle durch die mit der RHEL-Distribution ausgelieferten SELinux-Richtlinien geschützt
Anwendung von SELinux-Richtlinien auf Container
- Der Schutz erstreckt sich auch auf Container
- Container werden zunehmend zur bevorzugten Methode für Entwickler, Software bereitzustellen
- Es ist ein Irrtum zu glauben, dass etwas allein deshalb sicher ist, weil es in einem Container läuft
- Container selbst lösen Probleme der Softwarebereitstellung, nicht Sicherheitsprobleme
- Auf Red-Hat-basierten Distributionen kann
podman verwendet werden, eine Alternative zu Docker, die den Vorteil bietet, Container ohne Daemon und vollständig rootless auszuführen
- Red Hat geht noch einen Schritt weiter und wendet starke Standard-SELinux-Richtlinien an, die Container vom Host-OS und von anderen Containern isolieren
- Die Anwendung von SELinux-Richtlinien auf Container bietet verstärkte Schutzmechanismen, die das Risiko unbekannter zukünftiger Schwachstellen mindern
Red Hats Aufwand für Standard-SELinux-Richtlinien
- Red Hat wusste, dass Nutzer die Technologie nicht annehmen würden und Millionen von Servern verwundbar blieben, wenn diese Arbeit an Standardrichtlinien nicht geleistet würde
- SELinux ist schwierig, und die Richtliniensprache sowie die Werkzeuge sind komplex, obskur und ungefähr so attraktiv wie das Ausfüllen einer Steuererklärung
- Dank der Arbeit von Red Hat ist die Nutzung von SELinux unter RHEL jedoch weitgehend transparent und bietet den Nutzern reale Sicherheitsvorteile
Debians AppArmor-Ansatz
- Debian ist ein Kernstück der Open-Source-Community und bekannt für Stabilität und eine umfangreiche Softwarebibliothek
- Das grundlegende Sicherheits-Framework lässt jedoch viel Raum für Verbesserungen
- Die Entscheidung, AppArmor ab Debian 10 standardmäßig zu aktivieren, ist ein positiver Schritt zur Verbesserung der Sicherheit, bleibt aber unzureichend, weil sie systemweit nur halbherzig umgesetzt ist
- Debians Abhängigkeit von AppArmor und die Standardkonfiguration zeigen, dass es systematische Probleme im Sicherheitsansatz gibt
- AppArmor kann bei korrekter Konfiguration starke Sicherheit bieten, aber Debians Standardeinstellungen schöpfen dieses Potenzial nicht aus
Probleme mit AppArmor in Debian
- Begrenzte Standardprofile: Debian liefert nur einen minimalen Satz an AppArmor-Profilen aus, wodurch viele wichtige Dienste ungeschützt bleiben
- Reaktiv statt proaktiv: Debians Sicherheitsmodell verlässt sich oft darauf, dass Nutzer strengere Richtlinien selbst umsetzen, anstatt standardmäßig sichere Konfigurationen bereitzustellen
- Inkonsistente Anwendung: Anders als SELinux auf Red-Hat-Systemen wird AppArmor in Debian nur teilweise angewendet, was zu potenziellen Sicherheitslücken führt
- Ressourcenmangel: Als Community-getriebenes Projekt fehlen Debian die Ressourcen, um umfassende Sicherheitsrichtlinien ähnlich denen von Red Hat zu entwickeln und zu pflegen
Ausführung von Container-Workloads mit Docker auf Debian
- Es ist sehr verbreitet, Container-Workloads auf Debian über Docker auszuführen
- Docker erstellt und lädt automatisch ein Standard-AppArmor-Profil für Container namens
docker-default
- Leider ist dies kein sehr starkes Sicherheitsprofil und zu permissiv
- Dieses Profil bietet zwar einen gewissen Schutz, lässt aber eine erhebliche Angriffsfläche offen
Grundlegende Unterschiede zwischen AppArmor und SELinux
- Der grundlegende Unterschied zwischen AppArmor und SELinux liegt im Ansatz für Mandatory Access Control (MAC)
- AppArmor arbeitet mit einem pfadbasierten Modell, während SELinux ein deutlich komplexeres Type-Enforcement-System verwendet
- Diese Unterschiede treten insbesondere in Container-Umgebungen deutlich zutage
- SELinux weist allen Objekten im System Typen zu, darunter Dateien, Prozesse und Ports
- Wenn auf einem RHEL-System mit SELinux-Unterstützung ein Container gestartet wird, erhält er sofort den Typ
container_t, einen strikten Zugriffskontrollmechanismus
- Der Typ
container_t schottet den Container effektiv ab und verhindert, dass er mit Objekten interagiert, die nicht ausdrücklich für die Nutzung durch Container gelabelt sind
- SELinux bleibt nicht beim Type Enforcement stehen, sondern geht mit Multi-Category-Security-(MCS-)Labels bei der Containerisolierung noch einen Schritt weiter
- Diese Labels dienen als zusätzliche Trennungsebene und erhalten die Isolation sogar zwischen Containern desselben Typs (
container_t) aufrecht
- Jeder Container erhält ein eigenes MCS-Label und schafft damit eine private Sandbox innerhalb des größeren
container_t-Umfelds
Der Ansatz von AppArmor
- AppArmor kümmert sich nicht um Typen oder Kategorien, sondern konzentriert sich darauf, die Fähigkeiten bestimmter Programme anhand vordefinierter Profile einzuschränken
- Diese Profile legen fest, auf welche Dateien ein Programm zugreifen darf und welche Aktionen es ausführen kann
- Dieser Ansatz ist einfacher zu implementieren und zu verstehen, aber weder so granular noch so systemweit konsistent wie das Type Enforcement von SELinux
- Mainstream-Linux-Distributionen liefern standardmäßig keine umfassenden AppArmor-Profile für alle gängigen netzwerkorientierten Daemons aus
Praktische Auswirkungen
- In einer SELinux-Umgebung steht ein kompromittierter Container vor erheblichen Hürden, auf das Hostsystem oder andere Container zuzugreifen oder sie zu beeinflussen, dank der doppelten Barriere aus Type Enforcement und MCS-Labels
- SELinux bietet stärkere Isolation, allerdings um den Preis höherer Komplexität und potenziellen Performance-Overheads
- AppArmor bietet ein einfacheres und zugänglicheres Sicherheitsmodell, das bei richtiger Konfiguration weiterhin sehr effektiv sein kann
- Red Hat hat Anstrengungen unternommen, um den Einsatz von SELinux mit Containern reibungslos und einfach zu machen
- Letztlich ist die Wahl zwischen Debian und Red Hat nicht nur eine Wahl zwischen Konzernmacht und Community-getriebener Entwicklung
- Sie ist auch eine Wahl zwischen einem System, das vom Besten ausgeht, und einem System, das auf das Schlimmste vorbereitet ist
- In der heutigen hochgradig vernetzten Welt ist Pessimismus leider unverzichtbar
Meinung von GN⁺
- Die Änderung der Richtlinie zur Bereitstellung des RHEL-Quellcodes durch Red Hat ist umstritten, könnte aus Sicherheitssicht aber eine vernünftige Entscheidung sein
- In Enterprise-Linux-Distributionen ist die Bereitstellung starker Sicherheitsfunktionen wie SELinux unverzichtbar
- Allerdings könnte die Richtlinienänderung von Red Hat negative Auswirkungen auf das Open-Source-Ökosystem haben, wodurch die Rolle Community-basierter Distributionen wie Debian noch wichtiger werden dürfte
- Debian ist als benutzerfreundliche und flexible Distribution bekannt, muss seine Standardsicherheitsfunktionen jedoch stärken
- AppArmor ist zwar nicht so leistungsfähig wie SELinux, kann bei angemessener Konfiguration aber eine wirksame Sicherheitslösung sein
- Langfristig könnte die Entwicklung eines neuen Sicherheits-Frameworks nötig werden, das die Vorteile von SELinux und AppArmor kombiniert
- Containersicherheit ist im Cloud-native-Zeitalter ein sehr wichtiges Thema, daher sollten alle Distributionen in diesem Bereich mehr Anstrengungen unternehmen
2 Kommentare
Es stimmt zwar, dass AppArmor weniger strikt ist als SELinux..
aber daraus lässt sich kaum ableiten, dass die Sicherheit schwach ist.
SELinux ist so strikt, dass man es beim Einrichten eines Servers in den meisten Fällen einfach deaktiviert.
Und bei Desktops ist Sicherheit nicht das Hauptanliegen von SELinux.
Dort braucht es Einschränkungen für UI und Benutzererfahrung sowie passende Abläufe für Authentifizierungsanfragen, und das ist etwas anderes als die Isolierung von Ressourcen wie bei SELinux.
Deshalb basiert die Desktop-Sicherheit sowohl bei Red-Hat- als auch bei Debian-basierten Systemen auf dem in freedesktop standardisierten polkit (PolicyKit).
Hacker-News-Kommentare