Schwarze Markierung - wie OpenShift mit SELinux vor Container-Schwachstellen schützt

Haben Sie jemals einen schwierigen Job zum Wohl der Gesellschaft gemacht, aber Ihre Bemühungen nicht bemerkt, weil Sie so lange davon profitiert haben, dass jeder daran gewöhnt ist? Dies ist die Art von Arbeit für Sie, die alle Mitglieder der SELinux-Community leisten.



Und am 18. Februar dieses Jahres wurde die Welt vor allem dank ihrer Arbeit vor der gefährlichen Sicherheitslücke CVE-2019-5736 gerettet .

Obwohl es andere Betriebssysteme und andere Open Source-Projekte gibt, die Steuerelemente für Typ und Kategorie verwenden, sind selten alle mit SELinux konfigurierten Komponenten standardmäßig standardmäßig enthalten und einsatzbereit. Noch seltener deckt diese Konfiguration alle Ebenen ab, bis hin zur Lösung für die Container-Orchestrierung, auf deren Grundlage die öffentliche Cloud funktioniert.

Red Hat OpenShift verwendet seit acht Jahren Linux-Mechanismen zur erzwungenen Zugriffskontrolle wie Type Enforcement (TE) und Multi-Category Security (MCS). SELinux wird seit 2011 in OpenShift verwendet. Bei Red Hat OpenShift Online, einem öffentlich verfügbaren Hosting-Service, bei dem Tausende von Entwicklern täglich Container-Code ausführen, wurde SELinux von Anfang an verwendet. Was ist mit der Version von OpenShift, die beispielsweise im Rechenzentrum Ihres bevorzugten Mobilfunkbetreibers verwendet wird? Tatsächlich ist das SELinux-Sicherheitsmodul standardmäßig in der Red Hat OpenShift Container Platform enthalten! Und nicht nur eingeschaltet, sondern vollständig konfiguriert und bereit, sich vor echten Bedrohungen zu schützen.

Im Gegensatz zu anderen Kubernetes-Distributionen schließt Red Hat die Lücke zwischen Linux und der darauf installierten Container-Orchestrierungsplattform. Das heißt, Red Hat OpenShift überwacht und eliminiert Sicherheitsbedrohungen im gesamten Stapel und nicht nur in einer Schicht. Und dies erfolgt standardmäßig - ab dem ersten Arbeitstag.

OpenShift verwendet diese Konfiguration standardmäßig in Red Hat Enterprise Linux (Sie müssen nicht einmal wissen, was es gibt). Die Angelegenheit ist nicht auf die Ausführung von setenforce 1 auf einem Laptop beschränkt. Die Zugriffssteuerungsregeln für die Typen und Kategorien, die der Mandant für die Arbeit mit Containern in einem Kubernetes-Cluster anwendet, können auf Hunderte von Knoten erweitert werden, die von Tausenden anderer Mandanten verwendet werden können.

Überlegen Sie, wie die SELinux-Konfiguration mit MCS nach einigen Jahren in einem großen Unternehmen aussehen wird, das OpenShift-Anmeldeinformationen links und rechts verteilt. Stellen Sie sich nun vor, Sie geben Ihre Anmeldeinformationen ein, um sich bei Ihrem OpenShift-Cluster anzumelden, wie wir es bei openshift.com tun. Hingabe SELinux erhält häufig keine Anerkennung für alles, was in der OpenShift-Lösung ausgeführt wird. Wenn Ihnen das Betriebssystem heutzutage nicht so wichtig erscheint, überlegen Sie, ob Sie bis Februar dieses Jahres vor der Sicherheitsanfälligkeit CVE-2019-5736 geschützt waren. In OpenShift ist CVE-2019-5736 von Anfang an geschützt , und Sie können jetzt mit dieser Lösung fortfahren .

SELinux-Marken

Eine der effektivsten Standardsicherheitsfunktionen, die in Red Hat OpenShift implementiert sind, ist Security-Enhanced Linux (SELinux). SELinux ist ein Linux-Kernel-Sicherheitsmodul, das eine auf Sicherheitsrichtlinien basierende Zugriffskontrolle bietet. SELinux funktioniert so, dass allen Prozessen und Objekten des Betriebssystems Bezeichnungen (Namen) zugewiesen werden. Somit wird jedes Element, das an Kerneloperationen beteiligt ist, markiert und klassifiziert, und dann wird ihm Zugriff basierend auf einem vorhandenen Regelsatz gewährt.

Richtlinienregeln definieren die Beziehung zwischen gekennzeichneten Prozessen und gekennzeichneten Objekten. Vom Benutzer in den Richtlinien definierte Regeln werden auf Kernelebene angewendet. Standardmäßig wird alles, was nicht zulässig ist, automatisch verweigert - analog zu einer Firewall, die den Zugriff auf alle Prozesse verweigert, für die keine expliziten Berechtigungen konfiguriert sind. Die folgenden Abbildungen veranschaulichen einfache Anwendungsfälle.

Stellen Sie sich ein System vor, in dem Sie Typen für Objekte wie Katzen und Hunde definieren müssen. Katze und Hund sind Arten von Prozessen.


* Alle Zeichnungen stammen von Máirín Duffy

Die Klasse von Objekten, mit denen die Prozesse interagieren, ist Feed. Fügen Sie Futtertypen hinzu: cat_chow und dog_chow (Ohm-nom-nom).


Wir legen fest, dass der Hund Hundefutter (dog_chow) und das Katzenfutter (cat_chow) essen darf. Wir schreiben diese Berechtigungen als SELinux-Richtlinienregel:

allow cat cat_chow:food eat; allow dog dog_chow:food eat; 

Nach diesen Regeln darf der "cat" -Prozess auf Kernelebene Futter mit dem Label cat_chow und für das Hundefutter mit dem Label dog_chow essen.


Wir erinnern uns jedoch daran, dass in SELinux standardmäßig alles verboten ist. Wenn der Hund versucht, cat_chow zu essen, lässt der Kern dies nicht zu.


Dies ist die Typsteuerung, die eine wichtige Rolle beim Schutz des Hostsystems vor Containerprozessen spielt. Containerprozesse können nur Dateien aus dem Verzeichnis / usr lesen und ausführen und Daten nur in Containerdateien schreiben. Diese Einschränkung schützt den Host zuverlässig vor Containern, schützt jedoch einige Container nicht vor anderen, da sie alle mit demselben Typ gekennzeichnet sind. Um Container voreinander zu schützen, müssen Sie die MCS-Tag-Steuerung implementieren.

MCS zieht keine Katze am Schwanz

Die Verwendung von MCS steht nicht in direktem Zusammenhang mit dem Schutz von OpenShift vor CVE-2019-5736 . Es ist jedoch hilfreich, sich mit diesem Thema vertraut zu machen, um die Prinzipien der Verwendung von SELinux in OpenShift besser zu verstehen. Das Zuweisen von MCS-Labels aus Sicht des Benutzers oder Systemadministrators ist recht einfach. Sie müssen nur eine Reihe von Kategorien konfigurieren, bei denen es sich um einfache Textbeschriftungen handelt (z. B. Fido oder Spot), und ihnen Benutzer hinzufügen. Der Systemadministrator richtet zuerst die Kategorien ein und fügt ihnen dann Benutzer hinzu. Anschließend können Benutzer diese Beschriftungen nach Belieben verwenden. Dies ist praktisch, da Sie mit MCS Standard-SELinux-Tags zum Verwalten von Objekten verwenden können. Wenden wir uns noch einmal dem imaginären System aus dem obigen Beispiel zu.

Fügen Sie einen weiteren Teil des Etiketts hinzu, der auf den Hundeprozess und das dog_chow-Feed angewendet wird. Weisen Sie den Prozess "Hund" dem Hund zu: random1 (Fido) und dog: random2 (Spot).


Weisen wir dem Hundefutter die Bezeichnungen dog_chow: random1 (Fido) und dog_chow: random2 (Spot) zu.


Gemäß den Funktionsprinzipien von MCS ist der Zugriff zulässig, wenn die Regeln der erzwungenen Kontrolle durch Typ und beliebige MCS-Tags genau übereinstimmen, und in allen anderen Fällen wird der Zugriff verweigert.

Versuche von Fido (Hund: random1), cat_chow: zu essen, werden aufgrund erzwungener Typkontrollen abgelehnt.

Verteidigung in der Tiefe

Das von OpenShift verwendete Standard-SELinux-Sicherheitsmodul ist ein hervorragendes Beispiel für eine gründliche Verteidigung. OpenShift verwendet wie viele andere Kubernetes-basierte Plattformen SCC / PSP- Richtlinien, die das Ausführen von Containern mit Root-Rechten verbieten. Diese Einschränkung schützt auch vor CVE-2019-5736 . In OpenShift werden Container, deren Eigentümer der Root-Benutzer ist, standardmäßig blockiert. Dieser Parameter kann jedoch geändert werden . Selbst wenn Sie zulassen, dass Container als Root ausgeführt werden, schützt die Standard-SELinux-Konfiguration in OpenShift dennoch vor CVE-2019-5736 . Dies ist eine weitere Schutzstufe, die sich in dieser Situation wirklich auszahlt und bei weitem nicht die einzige in OpenShift ist. Weitere Informationen finden Sie in Dokument 10 Sicherheitsstufen für Container .

Weitere Informationen zu CVE-2019-5736 , einschließlich des Red Hat Enterprise Linux-Patches für die Container-Laufzeit, finden Sie in der Überprüfung der Red Hat-Sicherheitsanfälligkeit .