Marque noire - comment OpenShift protège contre les vulnérabilités des conteneurs avec SELinux

Avez-vous déjà fait un travail difficile pour le bien de la société, mais n’avez pas remarqué vos efforts, car vous en avez bénéficié pendant si longtemps que vous en êtes tous habitués? C'est le genre de travail que font tous les membres de la communauté SELinux .



Et le 18 février de cette année, grâce en grande partie à leur travail, le monde a été sauvé de la vulnérabilité dangereuse de collision de conteneurs CVE-2019-5736 .

Bien qu'il existe d'autres systèmes d'exploitation et d'autres projets open source qui utilisent des contrôles de type et de catégorie, il est rare que tous les composants configurés avec SELinux soient inclus par défaut, prêts à l'emploi. Plus rarement encore, cette configuration couvre tous les niveaux, jusqu'à la solution d'orchestration de conteneurs, sur la base de laquelle fonctionne le cloud public.

Red Hat OpenShift utilise des mécanismes de contrôle d'accès forcé Linux tels que l'application de type (TE) et la sécurité multi-catégories (MCS) depuis huit ans maintenant. SELinux est utilisé dans OpenShift depuis 2011. Chez Red Hat OpenShift Online, un service d'hébergement accessible au public où des milliers de développeurs exécutent quotidiennement du code conteneur, SELinux a été utilisé dès le départ. Qu'en est-il de la version d'OpenShift utilisée, par exemple, dans le centre de données de votre opérateur mobile préféré? En fait, le module de sécurité SELinux est inclus par défaut dans Red Hat OpenShift Container Platform! Et non seulement allumé, mais entièrement configuré et prêt à protéger contre les menaces réelles.

Contrairement à d'autres distributions Kubernetes, Red Hat comble le fossé entre Linux et la plate-forme d'orchestration de conteneurs installée au-dessus. Autrement dit, Red Hat OpenShift surveille et élimine les menaces de sécurité dans toute la pile, et pas seulement sur une seule couche. Et cela se fait par défaut - dès le premier jour de travail.

OpenShift utilise cette configuration par défaut dans Red Hat Enterprise Linux (vous n'avez même pas besoin de savoir de quoi il s'agit). Le problème ne se limite pas à exécuter setenforce 1 sur un ordinateur portable. Les règles de contrôle d'accès pour les types et catégories qu'un locataire applique pour travailler avec des conteneurs sur un cluster Kubernetes peuvent être étendues à des centaines de nœuds pouvant être utilisés par des milliers d'autres locataires.

Pensez à la façon dont la configuration SELinux avec MCS se comportera après quelques années d'utilisation dans une grande entreprise qui distribue les informations d'identification OpenShift à gauche et à droite. Imaginez maintenant que vous fournissez vos informations d'identification pour vous connecter à votre cluster OpenShift, comme nous le faisons sur openshift.com. La fidélité SELinux n'est souvent pas reconnue pour tout ce qu'elle fait dans une solution OpenShift. S'il vous semble que le système d'exploitation n'est pas si important de nos jours, demandez-vous si vous étiez protégé contre la vulnérabilité CVE-2019-5736 jusqu'en février. Dans OpenShift, CVE-2019-5736 est protégé dès le début, et vous pouvez passer à cette solution maintenant .

Marques SELinux

L'une des fonctionnalités de sécurité par défaut les plus efficaces implémentées dans Red Hat OpenShift est Linux sécurisé (SELinux). SELinux est un module de sécurité du noyau Linux qui fournit un contrôle d'accès basé sur une politique de sécurité. Le fonctionnement de SELinux consiste à attribuer des étiquettes (noms) à tous les processus et objets du système d'exploitation. Ainsi, chaque élément impliqué dans les opérations du noyau est marqué et classé, puis un accès lui est accordé sur la base d'un ensemble de règles existant.

Les règles de stratégie définissent la relation entre les processus balisés et les objets balisés. Les règles définies par l'utilisateur dans les politiques sont appliquées au niveau du noyau. Par défaut, tout ce qui n'est pas autorisé est automatiquement refusé - par analogie avec un pare-feu qui refuse l'accès à tous les processus pour lesquels des autorisations explicites ne sont pas configurées. Les illustrations ci-dessous illustrent des cas d'utilisation simples.

Imaginez un système dans lequel vous devez définir des types pour des objets tels que des chats et des chiens. Le chat et le chien sont des types de processus.


* Tous les dessins sont de Máirín Duffy

La classe d'objets avec laquelle les processus interagiront est le flux. Ajoutez des types de flux: cat_chow et dog_chow (Ohm-nom-nom).


Nous avons autorisé le chien à manger de la nourriture pour chien (dog_chow) et pour la nourriture pour chat - chat (cat_chow). Nous écrivons ces autorisations en tant que règle de politique SELinux:

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

Selon ces règles, le processus «chat» sera autorisé au niveau du noyau à manger de la nourriture avec l'étiquette cat_chow, et le chien sera autorisé à manger de la nourriture avec l'étiquette dog_chow.


Mais on se souvient que dans SELinux, par défaut, tout est interdit. Par conséquent, si le chien essaie de manger cat_chow, le noyau ne le permettra pas.


Il s'agit du contrôle de type, qui joue un rôle majeur dans la protection du système hôte contre les processus de conteneur. Les processus de conteneur peuvent uniquement lire et exécuter des fichiers à partir du répertoire / usr et écrire des données uniquement dans des fichiers de conteneur. Cette restriction protège de manière fiable l'hôte des conteneurs, mais ne protège pas certains conteneurs des autres, car ils sont tous marqués du même type. Pour protéger les conteneurs les uns des autres, vous devrez implémenter le contrôle des balises MCS.

MCS ne tire pas un chat par la queue

L'utilisation de MCS n'est pas directement liée à la protection d'OpenShift contre CVE-2019-5736 , mais il est utile de vous familiariser avec cette rubrique afin de mieux comprendre les principes d'utilisation de SELinux dans OpenShift. Attribuer des étiquettes MCS du point de vue de l'utilisateur ou de l'administrateur système est assez simple. Il vous suffit de configurer un ensemble de catégories qui sont de simples étiquettes de texte (par exemple, Fido ou Spot) et d'y ajouter des utilisateurs. L'administrateur système configure d'abord les catégories, puis leur ajoute des utilisateurs, après quoi les utilisateurs peuvent utiliser ces étiquettes à leur guise. C'est pratique car MCS vous permet d'utiliser des balises SELinux standard pour gérer les objets. Revenons à nouveau au système imaginaire de l'exemple ci-dessus.

Ajoutez une autre partie de l'étiquette qui sera appliquée au processus chien et au flux dog_chow. Attribuez le processus «chien» à chien: aléatoire1 (Fido) et chien: aléatoire2 (Spot).


Attribuons les étiquettes dog_chow: random1 (Fido) et dog_chow: random2 (Spot) à la nourriture pour chiens.


Selon les principes de fonctionnement de MCS, si les règles de contrôle forcé sont respectées par type et que les balises MCS arbitraires correspondent exactement, l'accès est autorisé et dans tous les autres cas, il est refusé.

Tentatives de Fido (chien: random1) de manger cat_chow: la nourriture sera refusée en raison de contrôles de type forcés.

Défense en profondeur

Le module de sécurité SELinux par défaut utilisé par OpenShift est un excellent exemple de défense en profondeur. OpenShift, comme de nombreuses autres plates-formes basées sur Kubernetes, utilise des stratégies SCC / PSP qui interdisent l'exécution de conteneurs avec des privilèges root. Cette limitation protège également contre CVE-2019-5736 . Dans OpenShift, les conteneurs appartenant à l'utilisateur root sont bloqués par défaut, mais ce paramètre peut être modifié . Même si vous autorisez les conteneurs à s'exécuter en tant que root, la configuration SELinux standard dans OpenShift protège toujours contre CVE-2019-5736 . C'est un autre niveau de protection qui est vraiment payant dans cette situation et il est loin d'être le seul dans OpenShift. De plus amples informations peuvent être trouvées dans le document 10 niveaux de sécurité des conteneurs .

Pour plus d'informations sur CVE-2019-5736 , y compris le correctif Red Hat Enterprise Linux pour le runtime du conteneur, consultez la revue de vulnérabilité de Red Hat .