Sécurité SELinux RHEL : Configuration et Dépannage

Introduction

Dans ce laboratoire, vous acquerrez une expérience pratique dans la gestion de la sécurité SELinux sous RHEL. Vous apprendrez à modifier les modes d'application de SELinux, de manière temporaire et persistante, et à configurer Apache avec des contextes de fichiers SELinux personnalisés. Le laboratoire couvre également l'ajustement de la politique SELinux pour les répertoires personnels des utilisateurs à l'aide de booléens et fournit des étapes pratiques pour le dépannage et la résolution des refus SELinux pour les serveurs web Apache et le contenu web personnalisé.

Modifier le mode d'application de SELinux

Dans cette étape, vous apprendrez à gérer les modes SELinux, de manière temporaire et persistante. SELinux (Security-Enhanced Linux) est un mécanisme de sécurité qui fournit un contrôle d'accès obligatoire (MAC - Mandatory Access Control) pour le noyau Linux. Il définit les droits d'accès pour les processus, les fichiers et autres ressources système.

SELinux fonctionne dans trois modes principaux :

Enforcing : La politique SELinux est appliquée. Les accès refusés par la politique sont bloqués et enregistrés. C'est le mode par défaut et le plus sécurisé.
Permissive : La politique SELinux n'est pas appliquée. Les accès refusés par la politique sont enregistrés mais pas bloqués. Ce mode est utile pour le dépannage et le test de nouvelles politiques.
Disabled : SELinux est désactivé. Aucune politique n'est chargée ou appliquée. Ce mode n'est généralement pas recommandé pour les systèmes de production.

Vous vous entraînerez à changer le mode SELinux à l'aide d'outils en ligne de commande et en modifiant les fichiers de configuration.

Tout d'abord, vérifions le mode d'application SELinux actuel.

Vérifier le mode d'application SELinux actuel.

Vous pouvez utiliser la commande getenforce pour voir rapidement le mode SELinux actuel.
```
getenforce
```
Vous devriez voir Enforcing en sortie, indiquant que SELinux applique actuellement ses politiques.
```
Enforcing
```
Changer temporairement le mode SELinux en permissive.

La commande setenforce vous permet de changer le mode SELinux au moment de l'exécution. Une valeur de 0 définit le mode sur permissive, et 1 le définit sur enforcing. Ce changement est temporaire et ne persistera pas après les redémarrages.
```
sudo setenforce 0
```
Maintenant, vérifiez le changement en utilisant à nouveau getenforce.
```
getenforce
```
La sortie devrait maintenant être Permissive.
```
Permissive
```
Changer temporairement le mode SELinux en enforcing.

Pour annuler le changement temporaire, utilisez setenforce 1.
```
sudo setenforce 1
```
Vérifiez à nouveau le mode.
```
getenforce
```
La sortie devrait être Enforcing à nouveau.
```
Enforcing
```
Changer de manière persistante le mode SELinux par défaut en permissive.

Pour rendre les changements de mode SELinux persistants après les redémarrages, vous devez modifier le fichier /etc/selinux/config. Ce fichier définit le mode SELinux par défaut pour le système.

Ouvrez le fichier de configuration en utilisant nano.
```
sudo nano /etc/selinux/config
```
Dans l'éditeur nano, trouvez la ligne qui commence par SELINUX= et changez sa valeur de enforcing à permissive.
```
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=permissive
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted
```
Appuyez sur Ctrl+X pour quitter, puis sur Y pour confirmer l'enregistrement, et sur Entrée pour écrire dans le même fichier.

Après avoir enregistré le fichier, vous pouvez confirmer le changement dans le fichier de configuration en utilisant grep.
```
grep '^SELINUX' /etc/selinux/config
```
La sortie devrait afficher SELINUX=permissive.
```
SELINUX=permissive
SELINUXTYPE=targeted
```
Note importante : Changer /etc/selinux/config ne modifie pas immédiatement le mode SELinux actif. Il ne définit que le mode qui sera appliqué après le prochain redémarrage du système. Pour voir le mode actif actuel, vous devez toujours utiliser getenforce.
```
getenforce
```
Il devrait toujours afficher Enforcing car le système n'a pas encore été redémarré.
```
Enforcing
```

Changer le mode SELinux par défaut en enforcing dans le fichier de configuration.

Maintenant, changeons le mode persistant en enforcing. C'est le paramètre recommandé et le plus sécurisé pour SELinux.

Ouvrez à nouveau le fichier de configuration.

sudo nano /etc/selinux/config

Changez le paramètre SELINUX= en enforcing.

## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=enforcing
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Enregistrez et quittez le fichier (Ctrl+X, Y, Entrée).

Confirmez le changement dans le fichier de configuration.

grep '^SELINUX' /etc/selinux/config

La sortie devrait maintenant afficher SELINUX=enforcing.

SELINUX=enforcing
SELINUXTYPE=targeted

À ce stade, le mode SELinux actif du système est toujours Enforcing (si vous n'avez pas redémarré après l'étape 4), et le paramètre persistant est également Enforcing.

Configurer Apache avec des contextes de fichiers SELinux personnalisés

Dans cette étape, vous apprendrez à configurer Apache pour servir du contenu web à partir d'un répertoire non standard et à gérer ses contextes de fichiers SELinux. Par défaut, les politiques SELinux restreignent Apache (httpd) à servir des fichiers uniquement à partir de répertoires spécifiques, principalement /var/www/html. Si vous placez du contenu web dans un autre emplacement, SELinux empêchera Apache d'y accéder, même si les permissions du système de fichiers sont correctes. C'est là que les contextes de fichiers SELinux entrent en jeu.

Un contexte de fichier SELinux est une étiquette appliquée à un fichier ou un répertoire qui définit ses attributs de sécurité. Pour qu'Apache serve du contenu à partir d'un emplacement personnalisé, cet emplacement et son contenu doivent avoir le contexte SELinux correct, généralement httpd_sys_content_t. Vous utiliserez semanage fcontext pour définir une règle persistante et restorecon pour l'appliquer.

Tout d'abord, vous devez installer le serveur HTTP Apache.

Installer le serveur HTTP Apache.

Utilisez le gestionnaire de paquets dnf pour installer le paquet httpd.
```
sudo dnf install -y httpd
```
Vous devriez voir une sortie indiquant l'installation réussie du paquet httpd et de ses dépendances.
Créer un répertoire personnalisé pour le contenu web et un fichier index.html.

Vous allez créer un nouveau répertoire nommé /custom et y placer un simple fichier index.html. Ce sera votre racine de documents web non standard.
```
sudo mkdir /custom
echo 'This is custom web content.' | sudo tee /custom/index.html
```
Vérifiez le contenu du fichier index.html.
```
cat /custom/index.html
```
```
This is custom web content.
```
Configurer Apache pour utiliser la nouvelle racine de documents.

Le fichier de configuration principal d'Apache est /etc/httpd/conf/httpd.conf. Vous devez modifier ce fichier pour pointer Apache vers votre nouveau répertoire /custom au lieu du répertoire par défaut /var/www/html.

Ouvrez le fichier de configuration en utilisant nano.
```
sudo nano /etc/httpd/conf/httpd.conf
```
Dans l'éditeur, trouvez les lignes DocumentRoot "/var/www/html" et <Directory "/var/www/html">. Remplacez toutes les occurrences de /var/www/html par /custom.

Les sections pertinentes devraient ressembler à ceci après modification :
```
#
## DocumentRoot: The directory out of which you will serve your
## documents. By default, all requests are taken from this directory, but
## symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/custom"

#
## Relax access to content within /var/www.
#
<Directory "/custom">
    AllowOverride None
    ## Allow open access:
    Require all granted
</Directory>
```
Enregistrez et quittez le fichier (Ctrl+X, Y, Entrée).
Démarrer et activer le service web Apache.

Après avoir modifié la configuration, vous devez démarrer le service httpd. Puisque vous êtes dans un environnement de conteneur, systemctl n'est pas disponible. Vous démarrerez httpd directement.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Le symbole & exécute la commande en arrière-plan, vous permettant de continuer à utiliser le terminal. Vous devriez voir une sortie similaire à celle-ci, indiquant qu'Apache démarre.
```
[1] 5094
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::216:3eff:fe00:63b%eth0. Set the 'ServerName' directive globally to suppress this message
```
Remarque : Le message d'avertissement concernant le nom de domaine complet du serveur est normal dans cet environnement de laboratoire et peut être ignoré en toute sécurité.

Pour vérifier qu'Apache est en cours d'exécution, vous pouvez rechercher le processus httpd.
```
ps aux | grep httpd
```
Vous devriez voir plusieurs processus httpd en cours d'exécution.
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Tenter d'accéder à la page web.

Maintenant, essayez d'accéder à votre page web en utilisant curl. Puisque vous êtes sur la même machine, vous pouvez utiliser localhost.
```
curl http://localhost/index.html
```
Remarque : Dans cet environnement particulier, vous constaterez peut-être que la page web est accessible même avec le contexte root_t. Cela démontre que, bien que SELinux soit en vigueur, le contexte root_t peut avoir des permissions plus larges que prévu. Cependant, pour les meilleures pratiques de sécurité et une configuration SELinux appropriée, le contenu web doit toujours utiliser le contexte httpd_sys_content_t approprié.
```
This is custom web content.
```
Vérifier le contexte SELinux actuel du répertoire personnalisé.

Utilisez la commande ls -Z pour afficher le contexte SELinux de votre répertoire /custom et du fichier index.html.
```
ls -Zd /custom /custom/index.html
```
Vous remarquerez qu'ils ont le contexte root_t, qui n'est pas le contexte recommandé pour le contenu web Apache.
```
system_u:object_r:root_t:s0 /custom
system_u:object_r:root_t:s0 /custom/index.html
```
Comparez cela à la racine de documents Apache par défaut :
```
ls -Zd /var/www/html
```
Vous verrez que /var/www/html a le contexte httpd_sys_content_t. C'est le contexte que vous devez appliquer à votre répertoire personnalisé.
```
system_u:object_r:httpd_sys_content_t:s0 /var/www/html
```
Définir une règle de contexte de fichier SELinux persistante pour /custom.

La commande semanage fcontext est utilisée pour gérer les règles de mappage de contexte de fichier SELinux. L'option -a ajoute une nouvelle règle, -t spécifie le type cible, et l'expression régulière '/custom(/.*)?' correspond au répertoire /custom lui-même et à tous les fichiers et sous-répertoires qu'il contient.
```
sudo semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'
```
Cette commande ajoute la règle à la politique SELinux, mais elle ne modifie pas immédiatement les contextes des fichiers existants.
Appliquer les nouveaux contextes SELinux aux fichiers.

La commande restorecon est utilisée pour restaurer les contextes SELinux des fichiers et des répertoires à leurs valeurs par défaut telles que définies par la politique. L'option -R applique la modification de manière récursive, et -v fournit une sortie détaillée.
```
sudo restorecon -Rv /custom
```
Vous devriez voir une sortie indiquant que les contextes de /custom et /custom/index.html ont été ré-étiquetés.
```
Relabeled /custom from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /custom/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
```
Vérifiez à nouveau les contextes en utilisant ls -Z.
```
ls -Zd /custom /custom/index.html
```
Ils devraient maintenant avoir le contexte httpd_sys_content_t.
```
system_u:object_r:httpd_sys_content_t:s0 /custom
system_u:object_r:httpd_sys_content_t:s0 /custom/index.html
```
Accéder à nouveau à la page web.

Maintenant que les contextes SELinux sont corrects, essayez d'accéder à la page web avec curl à nouveau.
```
curl http://localhost/index.html
```
Vous devriez maintenant voir le contenu de votre fichier index.html.
```
This is custom web content.
```
Enfin, arrêtez le processus du serveur HTTP Apache.
```
sudo pkill httpd
```
Vérifiez qu'aucun processus httpd n'est en cours d'exécution.
```
ps aux | grep httpd
```
Vous ne devriez voir que le processus grep lui-même.
```
labex     ... grep httpd
```

Ajuster la politique SELinux pour les répertoires personnels des utilisateurs avec des booléens

Dans cette étape, vous apprendrez à ajuster la politique SELinux en utilisant des Booleans pour permettre à Apache de servir du contenu web à partir des répertoires personnels des utilisateurs. Par défaut, SELinux empêche les services comme Apache d'accéder aux fichiers dans les répertoires personnels des utilisateurs pour des raisons de sécurité. Cependant, il existe des scénarios spécifiques, tels que les pages web personnelles, où cette fonctionnalité est souhaitée.

Les Booleans SELinux sont des paramètres vrai/faux qui permettent aux administrateurs de modifier le comportement de la politique SELinux sans écrire de politiques personnalisées complexes. Ils offrent un moyen flexible d'activer ou de désactiver certaines fonctionnalités de sécurité. Par exemple, il existe un Boolean spécifiquement pour autoriser Apache à accéder aux répertoires personnels des utilisateurs.

Activer la fonctionnalité de répertoire utilisateur d'Apache.

Apache possède un module appelé mod_userdir qui permet aux utilisateurs de publier du contenu web à partir d'un répertoire public_html dans leur répertoire personnel (par exemple, ~/public_html). Cette fonctionnalité est généralement configurée dans /etc/httpd/conf.d/userdir.conf. Par défaut, cette fonctionnalité est souvent désactivée.

Ouvrez le fichier de configuration en utilisant nano.
```
sudo nano /etc/httpd/conf.d/userdir.conf
```
Dans l'éditeur, vous trouverez des lignes liées à UserDir. Vous devez commenter la ligne qui désactive UserDir et décommenter la ligne qui l'active pour public_html.

Changer :
```
UserDir disabled
#UserDir public_html
```
En :
```
#UserDir disabled
UserDir public_html
```
Enregistrez et quittez le fichier (Ctrl+X, Y, Entrée).
Créer un répertoire public_html et un fichier index.html dans votre répertoire personnel.

Vous allez créer le répertoire public_html et un fichier index.html à l'intérieur. C'est là que votre contenu web personnel résidera.
```
mkdir ~/public_html
echo 'This is labex user content.' > ~/public_html/index.html
```
Vérifiez le contenu du fichier index.html.
```
cat ~/public_html/index.html
```
```
This is labex user content.
```
Informationnel : Lorsque vous avez créé le répertoire ~/public_html, il a été automatiquement configuré avec les contextes SELinux user_home_t et ~/ (votre répertoire personnel) avec home_dir_t. Le processus du serveur web Apache (httpd_t) ne peut pas lire les fichiers étiquetés user_home_t ou home_dir_t par défaut en raison de la politique SELinux.
Démarrer le service web Apache.

Démarrez le service httpd. N'oubliez pas que systemctl n'est pas disponible dans cet environnement de conteneur, vous démarrerez donc httpd directement.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Vous pouvez voir un message d'avertissement concernant le nom de domaine complet du serveur, qui peut être ignoré en toute sécurité dans cet environnement de laboratoire.

Vérifiez qu'Apache est en cours d'exécution.
```
ps aux | grep httpd
```
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Tenter d'accéder à la page web de l'utilisateur et observer le refus SELinux.

Maintenant, essayez d'accéder à votre page web personnelle en utilisant curl. L'URL des répertoires utilisateur suit généralement le format http://localhost/~username/.
```
curl http://localhost/~labex/index.html
```
Vous recevrez probablement une erreur "Forbidden", indiquant qu'Apache est toujours incapable d'accéder au contenu en raison de SELinux.
```
<!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 /~labex/index.html
on this server.<br />
</p>
</body></html>
```
Vérifier les Booleans SELinux liés aux répertoires personnels pour httpd.

La commande getsebool vous permet d'afficher l'état actuel des Booleans SELinux. Vous pouvez filtrer la sortie en utilisant grep pour trouver les Booleans liés à httpd et aux répertoires personnels.
```
sudo getsebool -a | grep httpd | grep home
```
Vous devriez voir httpd_enable_homedirs --> off, indiquant que ce Boolean est actuellement désactivé.
```
httpd_enable_homedirs --> off
```
Activer de manière persistante le Boolean httpd_enable_homedirs.

La commande setsebool est utilisée pour modifier l'état des Booleans SELinux. L'option -P rend la modification persistante après les redémarrages.
```
sudo setsebool -P httpd_enable_homedirs on
```
Vérifiez que le Boolean est maintenant on.
```
sudo getsebool -a | grep httpd | grep home
```
```
httpd_enable_homedirs --> on
```
Définir les permissions de fichier correctes pour le répertoire personnel.

Même avec le Boolean SELinux activé, Apache a besoin des permissions de système de fichiers appropriées pour accéder à votre répertoire personnel et au répertoire public_html. Par défaut, les répertoires personnels des utilisateurs ne sont pas accessibles à l'utilisateur Apache.
```
chmod 711 ~
chmod 755 ~/public_html
chmod 644 ~/public_html/index.html
```
Accéder à nouveau à la page web.

Maintenant que le Boolean httpd_enable_homedirs est activé et que les permissions de fichier sont correctes, essayez d'accéder à nouveau à votre page web personnelle avec curl.
```
curl http://localhost/~labex/index.html
```
Vous devriez maintenant voir le contenu de votre fichier index.html.
```
This is labex user content.
```
Dépannage : Si vous rencontrez toujours des problèmes d'accès même après avoir activé le Boolean et défini les permissions de fichier, cela démontre la nature multicouche de la sécurité Linux. Dans certains environnements, des facteurs supplémentaires tels que :
- Les directives de configuration Apache dans /etc/httpd/conf.d/userdir.conf
- Les contextes de fichiers SELinux sur la structure du répertoire personnel
- Des modules Apache ou des paramètres de sécurité supplémentaires
peuvent devoir être pris en compte. Le principal point d'apprentissage est de comprendre comment les Booleans SELinux fonctionnent en conjonction avec les permissions de fichiers traditionnelles et les configurations spécifiques aux applications.
Arrêter le processus du serveur HTTP Apache.

Enfin, arrêtez le processus du serveur HTTP Apache.
```
sudo pkill httpd
```
Vérifiez qu'aucun processus httpd n'est en cours d'exécution.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Dépannage des refus SELinux pour le serveur web Apache

Dans cette étape, vous apprendrez à identifier et à dépanner les refus de sécurité SELinux, en vous concentrant spécifiquement sur les problèmes qui pourraient empêcher le serveur web Apache de fonctionner correctement. Lorsque SELinux bloque une opération, il enregistre un message de refus "Access Vector Cache" (AVC). Ces messages sont cruciaux pour comprendre pourquoi une opération a échoué et comment la résoudre.

Vous utiliserez des outils comme auditd (le démon du système d'audit Linux) et sealert pour analyser ces messages de refus. auditd collecte les appels système et les événements, y compris les refus SELinux, et les stocke dans /var/log/audit/audit.log. L'outil sealert, qui fait partie du paquet setroubleshoot-server, peut analyser ces journaux et fournir des explications lisibles par l'homme et des solutions suggérées pour les refus SELinux.

Tout d'abord, vous devez vous assurer que auditd et setroubleshoot-server sont installés.

Installer auditd et setroubleshoot-server.
```
sudo dnf install -y audit setroubleshoot-server
```
Vous devriez voir une sortie indiquant l'installation réussie de ces paquets.
Démarrer le serveur web Apache et créer un fichier problématique.

Pour simuler un refus SELinux, vous allez créer un fichier avec un contexte SELinux incorrect et essayer de le servir avec Apache.

Tout d'abord, assurez-vous qu'Apache est en cours d'exécution.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Maintenant, créez un nouveau répertoire et un fichier index.html à l'intérieur. Cette fois, vous définirez intentionnellement un contexte SELinux incorrect pour ce fichier afin de déclencher un refus.
```
sudo mkdir /testweb
echo 'This is a test page.' | sudo tee /testweb/index.html
```
Par défaut, /testweb/index.html aura probablement le contexte root_t. Confirmons.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Maintenant, configurons Apache pour servir à partir de /testweb. Ouvrez /etc/httpd/conf/httpd.conf.
```
sudo nano /etc/httpd/conf/httpd.conf
```
Remplacez DocumentRoot et la directive <Directory> par /testweb.
```
DocumentRoot "/testweb"

<Directory "/testweb">
    AllowOverride None
    Require all granted
</Directory>
```
Enregistrez et quittez (Ctrl+X, Y, Entrée).

Redémarrez Apache pour appliquer les modifications de configuration. Puisque vous êtes dans un conteneur, vous devez tuer l'ancien processus et en démarrer un nouveau.
```
sudo pkill httpd
sudo /usr/sbin/httpd -DFOREGROUND &
```
Tenter d'accéder à la page web.

Essayez d'accéder à la page web en utilisant curl.
```
curl http://localhost/index.html
```
Note importante : Dans cet environnement, vous constaterez peut-être que la page web est accessible même avec le contexte root_t, comme nous l'avons observé à l'étape 2. Cela démontre que, bien que SELinux soit en vigueur, le contexte root_t a des permissions plus larges que les contextes plus restrictifs.
```
This is a test page.
```
Cependant, dans le but d'apprendre les techniques de dépannage SELinux, nous procéderons comme s'il y avait un refus. Dans des environnements SELinux plus restrictifs ou avec des configurations de politique différentes, l'accès aux fichiers avec des contextes inappropriés générerait en effet des refus.
Apprendre à examiner les refus SELinux en utilisant ausearch.

La commande ausearch est utilisée pour interroger les journaux d'audit. Vous pouvez rechercher les refus AVC SELinux (-m AVC) qui se sont produits aujourd'hui (-ts today).
```
sudo ausearch -m AVC -ts today
```
Remarque : Puisque la page web était accessible dans notre environnement, vous ne verrez peut-être aucun refus AVC récent lié à ce test spécifique. Cependant, cette commande produirait normalement des entrées de journal d'audit détaillées s'il y avait des refus. Dans un scénario de refus typique, vous recherchez des entrées liées à httpd et /testweb/index.html.

Une entrée de refus AVC typique ressemblerait à ceci :
```
----
time->...
type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=... comm="httpd" path="/testweb/index.html" dev="overlay" ino=... scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
...output omitted...
```
Les parties clés d'un refus AVC seraient :
- denied { getattr } : L'opération qui a été refusée (obtenir les attributs du fichier).
- comm="httpd" : Le processus qui a été refusé (serveur HTTP Apache).
- path="/testweb/index.html" : Le fichier auquel on a accédé.
- scontext=system_u:system_r:httpd_t:s0 : Le contexte SELinux de la source (Apache).
- tcontext=system_u:object_r:root_t:s0 : Le contexte SELinux de la cible (votre fichier index.html).
- tclass=file : Le type de cible (un fichier).
Cette sortie montre clairement que httpd_t (Apache) s'est vu refuser l'accès getattr à un fichier avec le contexte default_t.
Apprendre à utiliser sealert pour l'analyse SELinux.

sealert peut analyser les journaux d'audit et fournir des informations plus conviviales. Vous pouvez soit exécuter sealert -a pour analyser tous les refus récents, soit utiliser sealert -l <UUID> si vous avez un UUID spécifique à partir d'un message setroubleshoot dans /var/log/messages.
```
sudo sealert -a /var/log/audit/audit.log
```
Remarque : Puisque nous n'avons pas rencontré de refus réels dans cet environnement, l'exécution de sealert peut ne pas afficher de résultats liés à notre exemple /testweb. Cependant, dans un scénario où des refus SELinux se produisent, sealert analyserait le journal d'audit et présenterait un résumé.

Une sortie sealert typique pour un problème de contexte httpd ressemblerait à ceci :
```
SELinux is preventing /usr/sbin/httpd from getattr access on the file /testweb/index.html.

***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /testweb/index.html
Do ## semanage fcontext -a -t FILE_TYPE '/testweb/index.html'
where FILE_TYPE is one of the following:
httpd_sys_content_t, httpd_sys_script_exec_t, httpd_unconfined_script_exec_t, ...

***** Plugin httpd_can_network_connect (93.8 confidence) suggests *********
If you want to allow httpd to connect to the network (for example, to a database)
Then you must set the httpd_can_network_connect boolean to on.
Do ## setsebool -P httpd_can_network_connect on
...output omitted...
```
La sortie sealert serait très utile dans les scénarios de refus réels. Elle indiquerait explicitement le problème et suggérerait des solutions, telles que la modification de l'étiquette avec semanage fcontext -a -t FILE_TYPE '/testweb/index.html' et la liste de httpd_sys_content_t comme FILE_TYPE approprié.

Enfin, arrêtez le processus du serveur HTTP Apache.
```
sudo pkill httpd
```
Vérifiez qu'aucun processus httpd n'est en cours d'exécution.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Résoudre les problèmes SELinux pour le contenu web personnalisé

Dans cette dernière étape, vous appliquerez les connaissances acquises lors de l'exercice de dépannage précédent pour résoudre le refus SELinux qui empêchait Apache de servir du contenu à partir du répertoire /testweb. Vous utiliserez semanage fcontext pour définir le contexte SELinux correct pour votre contenu web personnalisé et restorecon pour l'appliquer.

Ce processus renforce la compréhension du fonctionnement des contextes SELinux et de la manière de les configurer correctement pour les services comme Apache.

S'assurer qu'Apache est en cours d'exécution et que la configuration est en place.

Tout d'abord, assurez-vous qu'Apache est configuré pour servir à partir de /testweb et qu'il est en cours d'exécution. Si vous avez arrêté Apache à l'étape précédente, redémarrez-le.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Vérifiez que le DocumentRoot dans /etc/httpd/conf/httpd.conf est défini sur /testweb. Sinon, modifiez-le comme vous l'avez fait à l'étape précédente.
```
grep "DocumentRoot" /etc/httpd/conf/httpd.conf
```
```
DocumentRoot "/testweb"
```
Confirmez également que /testweb/index.html existe et a le contexte root_t.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Accéder à la page web pour confirmer le comportement actuel.

Vérifions que la page web est actuellement accessible avec le contexte root_t.
```
curl http://localhost/index.html
```
Comme nous l'avons vu précédemment, la page est accessible même avec le contexte root_t.
```
This is a test page.
```
Bien que cela fonctionne, nous allons procéder pour démontrer la configuration SELinux appropriée pour le contenu web.
Définir le contexte de fichier SELinux correct pour /testweb.

Le contexte SELinux correct pour le contenu web servi par Apache est httpd_sys_content_t. Vous devez ajouter une règle persistante en utilisant semanage fcontext.
```
sudo semanage fcontext -a -t httpd_sys_content_t '/testweb(/.*)?'
```
Cette commande indique à SELinux que tous les fichiers ou répertoires dans /testweb (y compris /testweb lui-même) doivent être étiquetés avec httpd_sys_content_t.

Appliquer les nouveaux contextes SELinux aux fichiers.

Après avoir défini la règle, vous devez l'appliquer aux fichiers existants en utilisant restorecon.

sudo restorecon -Rv /testweb

Vous devriez voir une sortie indiquant que les contextes ont été réétiquetés.

Relabeled /testweb from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /testweb/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0

Vérifiez à nouveau les contextes en utilisant ls -Z.

ls -Z /testweb/index.html

system_u:object_r:httpd_sys_content_t:s0 /testweb/index.html

Accéder à nouveau à la page web pour confirmer la configuration correcte.

Maintenant que les contextes SELinux sont correctement appliqués conformément aux meilleures pratiques, essayez d'accéder à nouveau à la page web avec curl.
```
curl http://localhost/index.html
```
Le contenu devrait toujours être accessible, et il est maintenant correctement configuré avec le contexte SELinux recommandé.
```
This is a test page.
```
Cela démontre que, bien que le contexte root_t puisse fonctionner dans cet environnement, l'utilisation du contexte httpd_sys_content_t approprié suit les meilleures pratiques SELinux et garantit la compatibilité entre différentes configurations de sécurité.

Enfin, arrêtez le processus du serveur HTTP Apache.
```
sudo pkill httpd
```
Vérifiez qu'aucun processus httpd n'est en cours d'exécution.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Résumé

Dans ce laboratoire, vous avez appris à gérer la sécurité SELinux dans RHEL. Vous avez commencé par comprendre et pratiquer comment modifier les modes d'application de SELinux, à la fois temporairement en utilisant setenforce et de manière persistante en modifiant /etc/selinux/config. Cela comprenait la vérification du mode actuel avec getenforce et la compréhension des implications des modes Enforcing, Permissive et Disabled.

De plus, vous avez acquis une expérience pratique dans la configuration d'Apache avec des contextes de fichiers SELinux personnalisés en utilisant semanage fcontext et restorecon pour assurer le bon fonctionnement du serveur web. Vous avez également appris à ajuster la politique SELinux pour les répertoires personnels des utilisateurs en activant des booléens SELinux spécifiques avec setsebool. Enfin, le laboratoire a couvert les techniques essentielles de dépannage pour les refus SELinux, en particulier pour le serveur web Apache, en analysant les journaux d'audit avec ausearch et audit2allow pour identifier et résoudre les problèmes d'accès pour le contenu web personnalisé.

Gérer la sécurité SELinux dans RHEL