Introduction
Dans cet atelier, vous apprendrez à gérer les contextes de fichiers SELinux pour garantir que des services tels que le serveur web Apache puissent accéder aux fichiers nécessaires. Vous explorerez comment Security-Enhanced Linux (SELinux) applique des étiquettes de sécurité, appelées contextes, aux fichiers et comment des contextes inappropriés peuvent entraîner des erreurs de refus d'accès, même lorsque les permissions de fichiers standard semblent correctes. Cette expérience pratique est conçue pour renforcer vos compétences en matière de résolution de problèmes de sécurité courants dans un environnement Linux.
Tout au long des étapes, vous installerez Apache, vérifierez que SELinux est en mode enforcing (application stricte) et observerez le contexte par défaut d'une page web correctement placée. Vous provoquerez ensuite intentionnellement une erreur « Forbidden » (Interdit) en déplaçant un fichier avec un contexte incorrect dans le répertoire racine du serveur web. Pour résoudre ce problème, vous utiliserez la commande chcon afin de réétiqueter le fichier, illustrant ainsi une méthode fondamentale pour corriger les problèmes liés aux contextes SELinux et restaurer la fonctionnalité du service.
Installer Apache et vérifier que SELinux est en mode Enforcing
Dans cette étape, vous commencerez par vous assurer que votre environnement est correctement configuré. Cela implique de vérifier que Security-Enhanced Linux (SELinux), un module de sécurité critique du noyau Linux, fonctionne en mode enforcing. Ensuite, vous installerez le serveur web Apache, qui sera utilisé tout au long de cet atelier pour démontrer le fonctionnement des contextes SELinux.
Tout d'abord, vérifions le statut de SELinux. Vous pouvez le faire avec la commande sestatus, qui fournit une vue d'ensemble détaillée, ou la commande getenforce pour une réponse directe.
Exécutez getenforce pour voir le mode actuel :
getenforce
La commande devrait renvoyer Enforcing, ce qui signifie que SELinux protège activement votre système.
Enforcing
Si elle renvoie Permissive, SELinux enregistre les avertissements mais ne bloque pas les actions. Si elle renvoie Disabled, SELinux est complètement désactivé. Pour cet atelier, il doit être en mode Enforcing. Votre environnement d'apprentissage est préconfiguré pour être dans ce mode.
Ensuite, vous allez installer le serveur web Apache, connu sous le nom de paquet httpd sur les systèmes CentOS/RHEL. Utilisez le gestionnaire de paquets yum pour l'installer. L'option -y répond automatiquement « oui » à toutes les demandes de confirmation.
sudo yum -y install httpd
Vous verrez défiler les informations pendant que yum résout les dépendances et installe les paquets. Une installation réussie se terminera par un message « Complete! ».
...
Installed:
httpd-2.4.x-xx.el8.x86_64
...
Complete!
Une fois l'installation terminée, vous devez démarrer le service Apache pour qu'il soit opérationnel. Utilisez systemctl pour gérer le service.
sudo systemctl start httpd
Pour confirmer que le service Apache fonctionne correctement, vérifiez son statut :
sudo systemctl status httpd
La sortie devrait indiquer que le service est active (running).
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: active (running) since ...
...
Appuyez sur q pour quitter la vue du statut et revenir à l'invite de commande. Votre environnement est maintenant prêt pour les étapes suivantes.
Créer une page web et vérifier son contexte SELinux par défaut
Dans cette étape, vous allez créer une page web simple et la diffuser via le serveur Apache que vous venez d'installer. Ce processus démontrera comment SELinux attribue automatiquement le bon contexte de sécurité aux fichiers créés dans des répertoires spécifiques définis par la politique de sécurité, permettant ainsi aux services d'y accéder sans problème.
Le répertoire par défaut pour le contenu web sur Apache est /var/www/html. Tout fichier placé ici devrait être accessible via un navigateur web si ses permissions et son contexte SELinux sont corrects.
Créons un fichier index.html simple directement dans /var/www/html. Comme ce répertoire appartient à l'utilisateur root, vous devez utiliser sudo pour y écrire. Une commande sudo echo standard avec redirection (>) ne fonctionnerait pas car la redirection est gérée par votre shell actuel, qui n'a pas les permissions nécessaires. Pour résoudre cela, vous pouvez exécuter la commande dans un shell root via sudo sh -c '...'.
Exécutez la commande suivante pour créer le fichier :
sudo sh -c 'echo "Welcome to Apache on LabEx" > /var/www/html/index.html'
Maintenant, vérifions que le serveur web peut accéder à cette nouvelle page et la servir. Vous pouvez utiliser curl, un outil en ligne de commande pour transférer des données avec des URL, pour demander la page depuis localhost.
curl http://localhost
Vous devriez voir le contenu de votre fichier index.html s'afficher dans le terminal, confirmant qu'Apache fonctionne et peut lire le fichier.
Welcome to Apache on LabEx
Alors, pourquoi cela a-t-il fonctionné sans accroc ? La réponse réside dans le contexte SELinux du fichier. Lorsque vous créez un fichier, SELinux lui attribue un contexte basé sur la politique du répertoire parent. Inspectons le contexte du fichier index.html que vous venez de créer à l'aide de la commande ls -Z. L'option -Z affiche le contexte de sécurité SELinux.
ls -Z /var/www/html/index.html
La sortie ressemblera à ceci :
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
La partie la plus importante de cette sortie est l'étiquette de contexte : system_u:object_r:httpd_sys_content_t:s0. Cette étiquette est composée de quatre parties : utilisateur:rôle:type:niveau. Pour cet atelier, nous nous concentrons sur le type, qui est httpd_sys_content_t.
La politique SELinux pour Apache (httpd) autorise explicitement les processus s'exécutant avec le type httpd_t à accéder aux fichiers étiquetés avec le type httpd_sys_content_t. Comme vous avez créé le fichier directement dans /var/www/html, il a hérité du bon contexte par défaut, et tout a fonctionné comme prévu.
Provoquer un refus SELinux en déplaçant un fichier avec un contexte incorrect
Dans cette étape, vous verrez ce qui se passe lorsqu'un fichier avec un contexte SELinux incorrect est déplacé dans le répertoire web d'Apache. C'est un scénario courant qui peut être déroutant si vous ne savez pas comment les contextes SELinux se comportent lors d'opérations sur les fichiers comme mv. Contrairement à la création d'un fichier directement dans un répertoire (qui lui fait hériter du contexte par défaut du parent), le déplacement d'un fichier conserve son contexte d'origine.
Tout d'abord, créons une nouvelle page web, page2.html, dans votre répertoire de travail actuel, ~/project.
echo "This is Page 2" > page2.html
Maintenant, vérifiez le contexte SELinux de ce nouveau fichier. Puisqu'il a été créé dans votre répertoire personnel de projet, il recevra un contexte par défaut attribué aux fichiers utilisateur.
ls -Z page2.html
La sortie affichera un type de contexte tel que user_home_t ou similaire, ce qui est la norme pour les fichiers dans le répertoire personnel d'un utilisateur.
system_u:object_r:user_home_t:s0 page2.html
Notez que le type est user_home_t. C'est différent du type httpd_sys_content_t qu'Apache est autorisé à consulter.
Ensuite, déplacez ce fichier vers la racine web d'Apache en utilisant la commande mv. Vous aurez besoin de sudo car le répertoire de destination /var/www/html appartient à root.
sudo mv page2.html /var/www/html/
La commande mv préserve le contexte SELinux du fichier source. Vérifions cela en examinant le contexte du fichier à son nouvel emplacement.
ls -Z /var/www/html/page2.html
Comme vous pouvez le constater, le contexte n'a pas changé. Il est toujours user_home_t, même si le fichier se trouve maintenant dans le répertoire /var/www/html.
system_u:object_r:user_home_t:s0 /var/www/html/page2.html
Maintenant, essayez d'accéder à cette nouvelle page en utilisant curl. SELinux bloquera l'accès en raison de l'incohérence du contexte.
curl http://localhost/page2.html
Vous recevrez une erreur « 403 Forbidden » de la part du serveur. Il ne s'agit pas d'un problème de permissions de fichiers traditionnel ; c'est SELinux qui applique sa politique de sécurité et refuse au processus httpd la lecture d'un fichier portant l'étiquette user_home_t.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /page2.html
on this server.</p>
</body></html>
Cela illustre un problème SELinux classique. Dans l'étape suivante, vous apprendrez comment corriger cela en modifiant le contexte du fichier.
Corriger le contexte du fichier avec chcon et vérifier l'accès
Dans cette étape, vous allez résoudre l'erreur « 403 Forbidden » de l'étape précédente en modifiant manuellement le contexte SELinux du fichier page2.html. Vous utiliserez la commande chcon (change context), un outil puissant pour modifier le contexte de sécurité des fichiers et des répertoires.
La commande chcon vous permet de modifier directement l'utilisateur, le rôle, le type ou le niveau d'un contexte SELinux. Pour cet exercice, vous n'avez besoin de changer que le type. Le type correct pour le contenu web qu'Apache peut lire est httpd_sys_content_t.
Pour corriger le problème, vous utiliserez chcon avec l'option -t pour spécifier le nouveau type pour page2.html. Comme le fichier est situé dans /var/www/html, vous devrez utiliser sudo pour modifier son contexte.
Exécutez la commande suivante pour mettre à jour le type SELinux de page2.html :
sudo chcon -t httpd_sys_content_t /var/www/html/page2.html
Maintenant que vous avez exécuté la commande, vérifions que le contexte a été mis à jour. Utilisez à nouveau ls -Z pour inspecter le contexte de sécurité du fichier.
ls -Z /var/www/html/page2.html
La sortie devrait maintenant montrer que le type est passé de user_home_t à httpd_sys_content_t.
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/page2.html
Avec le bon contexte SELinux en place, Apache devrait maintenant être en mesure d'accéder au fichier et de le servir. Testons cela en effectuant une nouvelle requête avec curl.
curl http://localhost/page2.html
Cette fois, la commande devrait réussir, et vous verrez le contenu de votre page web s'afficher dans le terminal.
This is Page 2
Vous avez diagnostiqué et résolu avec succès un problème d'accès lié à SELinux. Vous avez appris que le déplacement de fichiers préserve leur contexte d'origine et que chcon peut être utilisé pour ajuster manuellement le contexte afin de l'aligner sur la politique de sécurité, accordant ainsi l'accès à des services comme Apache. Il est important de noter que les modifications effectuées avec chcon peuvent ne pas persister après un réétiquetage complet du système de fichiers ; la commande restorecon est généralement utilisée pour appliquer le contexte par défaut défini par la politique.
Résumé
Dans cet atelier, vous avez appris à gérer les contextes de fichiers SELinux pour le serveur web Apache. Vous avez commencé par vérifier que SELinux était en mode Enforcing, puis vous avez installé et démarré le service httpd. Vous avez observé que les fichiers créés directement à la racine web d'Apache (/var/www/html) reçoivent automatiquement le contexte httpd_sys_content_t approprié, indispensable pour qu'Apache puisse y accéder et les diffuser correctement.
Le cœur de l'atelier a démontré les conséquences de contextes de fichiers incorrects. En déplaçant un fichier depuis le répertoire personnel d'un utilisateur (avec un contexte user_home_t) vers la racine web, vous avez déclenché un refus SELinux, entraînant une erreur « 403 Forbidden ». Vous avez ensuite appris à résoudre ce problème d'accès en utilisant la commande chcon pour changer manuellement le contexte du fichier vers le type httpd_sys_content_t correct, rétablissant ainsi l'accès et renforçant le principe selon lequel des contextes de fichiers corrects sont essentiels au bon fonctionnement des services sous une politique SELinux active.
