Introduction à SELinux sur CentOS 7 - Partie 2: Fichiers et processus

Dans la la première partie de notre série SELinux, nous avons vu comment activer et désactiver SELinux et comment modifier certains paramètres de stratégie à l’aide de valeurs booléennes. Dans cette seconde partie, nous aborderons les contextes de sécurité des fichiers et des processus.

Pour actualiser votre mémoire à partir du didacticiel précédent, un contexte de sécurité de fichier est un type et un contexte de sécurité de processus est un domaine.

_ * Remarque * + Les commandes, les packages et les fichiers présentés dans ce didacticiel ont été testés sur CentOS 7. Les concepts restent les mêmes pour les autres distributions. _

Dans ce tutoriel, nous exécuterons les commandes en tant qu’utilisateur root, sauf indication contraire. Si vous n’avez pas accès au compte root et utilisez un autre compte avec les privilèges sudo, vous devez faire précéder les commandes du mot-clé + sudo +.

Commençons par créer quatre comptes utilisateur pour démontrer les capacités de SELinux au fur et à mesure.

Vous devriez être actuellement l’utilisateur * root *. Lançons la commande suivante pour ajouter le compte * regularuser *:

Puis nous lançons la commande + passwd + pour changer son mot de passe:

La sortie nous demandera un nouveau mot de passe. Une fois fourni, le compte sera prêt pour la connexion:

Créons également les autres comptes:

Le but de SELinux est de sécuriser la manière dont les processus accèdent aux fichiers dans un environnement Linux. Sans SELinux, un processus ou une application telle que le démon Apache s’exécutera sous le contexte de l’utilisateur qui l’a lancé. Ainsi, si votre système est compromis par une application non autorisée exécutée sous l’utilisateur root, l’application peut faire ce qu’elle veut, car la racine dispose de droits complets sur chaque fichier.

SELinux tente d’aller plus loin et d’éliminer ce risque. Avec SELinux, un processus ou une application n’aura que les droits nécessaires pour fonctionner et RIEN de plus. La stratégie SELinux de l’application déterminera les types de fichiers auxquels elle doit accéder et les processus auxquels elle peut être transférée. Les stratégies SELinux sont écrites par les développeurs d’applications et livrées avec la distribution Linux qui les prend en charge. Une stratégie est fondamentalement un ensemble de règles qui mappent les processus et les utilisateurs sur leurs droits.

Nous commençons la discussion de cette partie du didacticiel en comprenant ce que signifient les contextes et les domaines de SELinux.

La première partie de la sécurité place un label sur chaque entité du système Linux. Une étiquette est comme n’importe quel autre attribut de fichier ou de processus (propriétaire, groupe, date de création, etc.); il montre le context de la ressource. Alors, quel est le contexte? En termes simples, un contexte est une collection d’informations liées à la sécurité qui aide SELinux à prendre des décisions en matière de contrôle d’accès. Tous les systèmes Linux peuvent avoir un contexte de sécurité: un compte utilisateur, un fichier, un répertoire, un démon ou un port peuvent tous avoir leur contexte de sécurité. Cependant, le contexte de sécurité signifiera différentes choses pour différents types d’objets. + ​

Avant d’aller plus loin, voici une note sur la convention de nommage de SELinux. Les utilisateurs de SELinux ont le suffixe «_u», les rôles le suffixe «_r» et les types (pour les fichiers) ou les domaines (pour les processus) le suffixe «_t».

Jusqu’à présent, nous avons vu que les fichiers et les processus peuvent avoir différents contextes et qu’ils sont limités à leurs propres types ou domaines. Alors, comment fonctionne un processus? Pour s’exécuter, un processus doit accéder à ses fichiers et y exécuter certaines actions (ouvrir, lire, modifier ou exécuter). Nous avons également appris que chaque processus ne peut avoir accès qu’à certains types de ressources (fichiers, répertoires, ports, etc.).

SELinux stipule ces règles d’accès dans une politique. Les règles d’accès suivent une structure standard allow statement:

Nous avons déjà parlé de domaines et de types. * Classe * définit ce que la ressource représente réellement (fichier, répertoire, lien symbolique, périphérique, ports, curseur, etc.)

Voici ce que signifie cette autorisation générique:

Pour voir comment cela fonctionne, considérons les contextes de sécurité du démon httpd exécuté sur notre système CentOS 7:

Le répertoire de base par défaut du serveur Web est + / var / www / html. Créons un fichier dans ce répertoire et vérifions son contexte:

Le contexte de fichier pour notre contenu Web sera * httpd_sys_content_t *:

Nous pouvons utiliser la commande + sesearch + pour vérifier le type d’accès autorisé pour le démon httpd:

Les indicateurs utilisés avec la commande sont assez explicites: le domaine source est * httpd_t *, le même domaine qu’Apache est exécuté. Nous nous intéressons aux ressources cibles qui sont des fichiers et dont le contexte de type est * httpd_sys_content_t *. Votre sortie devrait ressembler à ceci:

Remarquez la première ligne:

Cela indique que le démon httpd (le serveur Web Apache) dispose d’un contrôle d’E / S, d’une lecture, d’un attribut, d’un verrouillage et d’un accès ouvert aux fichiers du type * httpd_sys_content *. Dans ce cas, votre fichier + index.html a le même type.

Pour aller plus loin, commençons par modifier la page Web (+ / var / www / html / index.html). Editez le fichier pour qu’il contienne ce contenu:

Ensuite, nous allons changer l’autorisation du dossier + / var / www / + et son contenu, suivie d’un redémarrage du démon httpd:

Nous allons ensuite essayer d’y accéder depuis un navigateur:

image: https: //assets.digitalocean.com/articles/SELinuxCentOS7/2.jpg [Accès à une page Web avec le paramètre SELiunux correct]

_ * Remarque * + Selon la configuration de votre serveur, vous devrez peut-être activer le port 80 du pare-feu IPTables pour autoriser le trafic HTTP entrant en dehors du serveur. Nous n’entrerons pas dans les détails d’activation des ports dans IPTables ici. Il existe d’excellentes DigitalOcean articles sur le sujet qui vous intéresse. peut utiliser. _

Jusqu’ici tout va bien. Le démon httpd est autorisé à accéder à un type de fichier particulier et nous pouvons le voir lors de l’accès via le navigateur. Ensuite, changeons les choses en modifiant le contexte du fichier. Nous allons utiliser la commande + chcon + pour cela. L’indicateur + - type + de la commande nous permet de spécifier un nouveau type pour la ressource cible. Ici, nous changeons le type de fichier en * var_t *.

Nous pouvons confirmer le changement de type:

Ensuite, lorsque nous essayons d’accéder à la page Web (c.-à-d. le démon httpd tente de lire le fichier), vous pouvez obtenir une erreur * Forbidden * ou la page générique «Testing 123» de CentOS:

image: https: //assets.digitalocean.com/articles/SELinuxCentOS7/3.jpg [Accès à une page Web avec un paramètre SELinux incorrect]

Alors que se passe-t-il ici? De toute évidence, certains accès sont maintenant refusés, mais à qui appartient-il? En ce qui concerne SELinux, le serveur Web est autorisé à accéder à certains types de fichiers uniquement et var_t ne fait pas partie de ces contextes. Depuis que nous avons changé le contexte du fichier index.html en var_t, Apache ne peut plus le lire et nous obtenons une erreur.

Pour que les choses fonctionnent à nouveau, changeons le type de fichier avec la commande + restorecon +. Le commutateur -v affiche le changement des étiquettes de contexte:

Si nous essayons d’accéder à la page maintenant, notre texte «Ceci est une page Web de test» s’affichera à nouveau.

Il s’agit d’un concept important à comprendre: s’assurer que les fichiers et les répertoires ont le contexte correct est essentiel pour s’assurer que SELinux se comporte comme il se doit. Nous verrons un cas pratique à la fin de cette section, mais avant cela, parlons de quelques autres choses.

SELinux applique quelque chose que nous pouvons appeler «héritage de contexte». Cela signifie que, sauf spécification contraire de la politique, les processus et les fichiers sont créés avec les contextes de leurs parents.

Ainsi, si un processus appelé «proc_a» génère un autre processus appelé «proc_b», le processus généré s’exécutera dans le même domaine que «proc_a», sauf indication contraire de la politique SELinux.

De même, si nous avons un répertoire avec le type "some_context_t", tout fichier ou répertoire créé sous ce répertoire aura le même contexte de type, sauf indication contraire de la politique.

Pour illustrer cela, vérifions les contextes du répertoire + / var / www / +:

Le répertoire + html + dans + / var / www / + a le contexte de type * httpd_sys_content_t *. Comme nous l’avons vu précédemment, le fichier + index.html + qu’il contient a le même contexte (c’est-à-dire le contexte du parent):

Cet héritage n’est pas préservé lorsque les fichiers sont copiés vers un autre emplacement. Dans une opération de copie, le fichier ou le répertoire copié assumera le type de contexte de l’emplacement cible. Dans l’extrait de code ci-dessous, nous copions le fichier + index.html + (avec le contexte de type «httpd_sys_content_t») dans le répertoire + / var / +:

Si nous vérifions le contexte du fichier copié, nous verrons qu’il a été remplacé par * var_t *, le contexte de son répertoire parent actuel:

Ce changement de contexte peut être remplacé par la clause + - preserver = context de la commande` + cp`.

Lorsque des fichiers ou des répertoires sont déplacés, les contextes d’origine sont préservés. Dans la commande suivante, nous déplaçons le + / var / index.html + vers le répertoire + / etc / +:

Lorsque nous vérifions le contexte du fichier déplacé, nous constatons que le contexte * var_t * a été conservé dans le répertoire + / etc / +:

Alors, pourquoi sommes-nous si concernés par les contextes de fichiers? Pourquoi ce concept de copie et de déplacement est-il important? Pensez-y: vous avez peut-être décidé de copier tous les fichiers HTML de votre serveur Web dans un répertoire distinct, situé dans le dossier racine. Vous avez fait cela pour simplifier votre processus de sauvegarde et également pour renforcer la sécurité: vous ne voulez pas qu’un pirate informatique devine facilement où se trouvent les fichiers de votre site Web. Vous avez mis à jour le contrôle d’accès au répertoire, modifié le fichier de configuration Web pour qu’il pointe vers le nouvel emplacement, redémarré le service, mais cela ne fonctionne toujours pas. Peut-être pourrez-vous ensuite examiner les contextes du répertoire et de ses fichiers lors de la prochaine étape de résolution des problèmes. Examinons cela comme un exemple pratique.

Dans un exemple de code précédent, nous avons vu deux commandes permettant de modifier le contenu du fichier: + chcon + et + restorecon +. Lancer + chcon + est une mesure temporaire. Vous pouvez l’utiliser pour modifier temporairement les contextes de fichier ou de répertoire afin de résoudre les erreurs de refus d’accès. Cependant, cette méthode n’est que temporaire: un système de fichiers ré-étiqueté ou exécutant la commande + restorecon + ramènera le fichier à son contexte d’origine.

De plus, l’exécution de + chcon + nécessite que vous connaissiez le contexte correct pour le fichier; l’indicateur + - type + spécifie le contexte de la cible. + restorecon + n’a pas besoin de cela. Si vous exécutez + restorecon +, le fichier aura le contexte correct réappliqué et les modifications deviendront permanentes.

Mais si vous ne connaissez pas le bon contexte du fichier, comment le système sait-il quel contexte appliquer quand il exécute + restorecon +?

SELinux "se souvient" du contexte de chaque fichier ou répertoire du serveur. Dans CentOS 7, les contextes des fichiers existant déjà dans le système sont répertoriés dans le fichier + / etc / selinux / target / contexts / files / file_contexts +. C’est un fichier volumineux qui répertorie tous les types de fichiers associés à toutes les applications prises en charge par la distribution Linux. Les contextes de nouveaux répertoires et fichiers sont enregistrés dans le fichier + / etc / selinux / target / contexts / files / file_contexts.local +. Ainsi, lorsque nous exécuterons la commande + restorecon +, SELinux recherchera le contexte correct dans l’un de ces deux fichiers et l’appliquera à la cible.

L’extrait de code ci-dessous montre un extrait de l’un des fichiers:

Pour modifier en permanence le contexte de notre fichier index.html sous + / www / html +, nous devons suivre un processus en deux étapes.

Pour être sûr, nous pouvons vérifier la base de données de contexte de fichier (notez que nous utilisons le fichier + file_contexts.local +):

Vous devriez voir les contextes mis à jour:

Ensuite, nous lancerons la commande + restorecon +. Ceci va renommer le fichier ou le répertoire avec ce qui a été enregistré à l’étape précédente:

Cela devrait réinitialiser le contexte en trois niveaux: le répertoire de haut niveau + / www +, le répertoire + / www / html sous celui-ci et le fichier` + index.html` sous + / www / html +:

Si nous essayons maintenant d’accéder à la page Web, cela devrait fonctionner.

Il existe un outil astucieux appelé + matchpathcon + qui peut aider à résoudre les problèmes liés au contexte. Cette commande examine le contexte actuel d’une ressource et le compare à ce qui est répertorié dans la base de données de contexte SELinux. Si différent, il suggérera le changement requis. Voyons cela avec le fichier + / www / html / index.html +. Nous allons utiliser le drapeau + -V + qui vérifie le contexte:

La sortie + matchpathcon + devrait indiquer que le contexte est vérifié.

Pour un fichier mal étiqueté, le message indiquera quel devrait être le contexte:

Jusqu’à présent, nous avons vu comment les processus accèdent aux ressources du système de fichiers. Nous allons maintenant voir comment les processus accèdent à d’autres processus.

Domain transition est la méthode par laquelle un processus modifie son contexte d’un domaine à un autre. Pour le comprendre, supposons qu’un processus appelé proc_a s’exécute dans un contexte de contexta_t. Avec la transition de domaine, proc_a peut exécuter une application (un programme ou un script exécutable) appelée app_x qui spawn serait utilisée par un autre processus. Ce nouveau processus pourrait s’appeler proc_b et s’exécuter dans le domaine contextb_t. Tellement efficacement, contexta_t est transitioning à contextb_t via app_x. Le fichier exécutable app_x fonctionne comme un entrypoint pour contextb_t. Le flux peut être illustré ci-dessous:

image: https: //assets.digitalocean.com/articles/SELinuxCentOS7/4.jpg [Transition de domaine SELinux]

Le cas de la transition de domaine est assez courant dans SELinux. Considérons le processus vsftpd en cours d’exécution sur notre serveur. S’il n’est pas en cours d’exécution, nous pouvons exécuter la commande + service vsftpd start + pour démarrer le démon.

Ensuite, nous considérons le processus systemd. C’est l’ancêtre de tous les processus. Il s’agit du remplacement du processus init de System V et s’exécute dans un contexte de * init_t *. :

Le processus exécuté dans le domaine * init_t * est un processus de courte durée: il appelle l’exécutable binaire + / usr / sbin / vsftpd +, qui a un contexte de type * ftpd_exec_t *. Lorsque l’exécutable binaire démarre, il devient le démon vsftpd lui-même et s’exécute dans le domaine * ftpd_t *.

Nous pouvons vérifier les contextes de domaine des fichiers et des processus:

Montre nous:

Vérification du processus:

Montre nous:

Donc, ici, le processus exécuté dans le domaine * init_t * exécute un fichier binaire avec le type * ftpd_exec_t *. Ce fichier démarre un démon dans le domaine * ftpd_t *.

Cette transition n’est pas quelque chose que l’application ou l’utilisateur peut contrôler. Cela a été stipulé dans la politique SELinux qui est chargée en mémoire au démarrage du système. Sur un serveur non-SELinux, un utilisateur peut démarrer un processus en passant à un compte plus puissant (à condition qu’il en ait le droit). Dans SELinux, cet accès est contrôlé par des règles prédéfinies. C’est une autre raison pour laquelle on dit que SELinux implémente le contrôle d’accès obligatoire.

La transition de domaine est soumise à trois règles strictes:

En prenant l’exemple du démon vsftpd ci-dessus, exécutons la commande + sesearch + avec différents commutateurs pour voir si le démon est conforme à ces trois règles.

Tout d’abord, le domaine source init_t doit disposer de l’autorisation d’exécution sur l’application entrypoint avec le contexte ftpd_exec_t. Donc, si nous lançons la commande suivante:

Le résultat montre que les processus du domaine init_t peuvent lire, obtenir les attributs, exécuter et ouvrir les fichiers du contexte ftpd_exec_t:

Ensuite, nous vérifions si le fichier binaire est le point d’entrée du domaine cible ftpd_t:

Et en effet c’est ainsi:

Et enfin, le domaine source init_t doit avoir l’autorisation de passer au domaine cible ftpd_t:

Comme nous pouvons le voir ci-dessous, le domaine source dispose de cette autorisation:

Lorsque nous avons introduit le concept de domaine, nous l’avons comparé à une bulle hypothétique autour du processus: quelque chose qui indique ce que le processus peut et ne peut pas faire. C’est ce qui limite le processus.

SELinux a également des processus qui s’exécutent dans des domaines non restreints. Comme vous pouvez l’imaginer, les processus non confinés auraient tous les types d’accès dans le système. Même dans ce cas, cet accès complet n’est pas arbitraire: l’accès complet est également spécifié dans la stratégie SELinux.

Un exemple de domaine de processus non confiné serait unconfined_t. Il s’agit du même domaine connecté. Les utilisateurs exécutent leurs processus par défaut. Nous parlerons des utilisateurs et de leurs accès pour traiter les domaines dans les sections suivantes.

Nous avons couvert quelques concepts très importants de SELinux ici aujourd’hui. La gestion du contexte de fichier et de processus est au cœur d’une implémentation réussie de SELinux. Comme nous le verrons dans la prochaine partie et final de cette série, Une autre pièce du puzzle reste: l’utilisateur SELinux.