Introduction

SELinux (Security-Enhanced Linux) est une technologie de sécurité développée pour les systèmes d’exploitation Linux. Son objectif principal est de renforcer la sécurité en imposant des contrôles d’accès obligatoires basés sur des règles de sécurité, même en présence de vulnérabilités logicielles ou de failles de configuration.

L’idée fondamentale derrière SELinux est de restreindre les actions qu’un processus peut entreprendre sur un système, en fonction de ses droits et de ses rôles, afin de limiter les dommages potentiels résultant d’attaques ou d’erreurs de conception. Contrairement aux systèmes de contrôle d’accès traditionnels basés sur les utilisateurs et les groupes, SELinux se concentre sur les attributs de sécurité étendus tels que les étiquettes de sécurité et les règles de politique.

Voici quelques concepts clés associés à SELinux :

• Étiquettes de sécurité : Dans SELinux, chaque processus, fichier, socket, etc., se voit attribuer une étiquette de sécurité. Cette étiquette détermine les actions que le sujet (processus) peut effectuer sur l’objet (fichier, socket, etc.) en fonction des règles de sécurité définies.

• Politiques : Les politiques SELinux définissent les règles qui régissent les interactions entre les processus et les objets du système. Ils spécifient quel type d’accès est autorisé ou refusé en fonction des étiquettes de sécurité.
• Mode d’application : SELinux fonctionne généralement en trois modes : Enforcing (Appliquer), Permissive (Permissif) et Disabled (Désactivé). En mode Enforcing, SELinux applique strictement les règles de sécurité. En mode Permissive, SELinux génère des messages d’audit pour les violations potentielles, mais n’empêche pas les actions. En mode Disabled, SELinux est désactivé.
• Contexte de sécurité : Chaque objet dans le système (fichiers, processus, ports réseau, etc.) possède un contexte de sécurité qui comprend des informations sur l’utilisateur, le rôle et le type de l’objet. Ces contextes sont utilisés pour prendre des décisions de contrôle d’accès.
• Types de politiques : SELinux offre différents types de politiques, notamment le modèle ciblé (Targeted) qui est le plus couramment utilisé, et le modèle MLS (Multilevel Security) qui gère la sécurité en fonction des niveaux de classification et d’autorisation.

Utiliser au quotidien SELinux

Si les politiques SELinux sont généralement suffisante dans le cadre d’une utilisation poste de travail ou si notre service (daemon) respecte l’arborescence définie par la distribution. Il devient plus compliqué d’utiliser SELinux dans le cas ou nous souhaitons adapter la configuration à notre environnement. Par exemple, déplacer le répertoire /var/lib/mysql va avoir comme impact de modifier le contexte de sécurité des fichiers et donc, même si les fichiers appartiennent bien à l’utilisateur mysql, empecher l’accès du service au nouveau répertoire.

Désactivé temporairement SELinux

Il peut être difficile de devoir configurer un nouveau service dont on ne maîtrise pas la configuration et devoir gérer en même temps les restrictions SELinux. En général, il est plus simple de préparer une configuration fonctionnelle en désactivant temporairement SELinux. Cela permet de vérifier que les blocages que nous avons viennent bien des politiques de SELinux et non pas de problèmes de droits d’accès unix classique.

La désactivation temporaire sera active jusqu’au prochain reboot ou jusqu’à la réactivation de SELinux. Cette action se fait grâce à la commande setenforce

# Desactivation SELinux
bash-4.1$ setenforce 0
# Activation SELinux
bash-4.1$ setenforce 1

Voir et comprendre les blocages

Les messages SELinux sont remontés au système et peuvent être consulté dans le fichier /var/log/audit/audit.log ou dans le fichier /var/log/messages.

Lors d’un blocage, vous aurez des messages du type

type=AVC msg=audit(1693318031.676:532): avc:  denied  { append } for  pid=26702 comm="sendmail" path=[...]

qui indique qu’un process a été bloqué par SELinux. Sur les distributions les plus récentes, il existe une commande sealert qui permet de faire une analyse complète. Celle-ci à l’avantage de proposer une solution afin d’adapter les politiques SELinux à l’environnement que nous souhaitons mettre en place. La commande sealert à exécuter est noté dans le fichier /var/log/messages. Par exemple

Aug 30 00:07:31 [...] setroubleshoot[50050]: SELinux is preventing sendmail from append access on the file [...]. For complete SELinux messages run: sealert -l [...]

Le résultat de la commande est du type

[root@misp ~]# sealert -l 6a8c3b42-9fa6-4172-9c4f-cfd9c7e3e082
SELinux interdit à sendmail d'utiliser l'accès append sur le fichier [...].

*****  Le greffon restorecon (99.5 de confiance) suggère   *******************

Si vous souhaitez corriger l'étiquette. 
L'étiquette par défaut de [...] devrait être httpd_log_t.
Alors vous pouvez lancer restorecon. La tentative d’accès pourrait avoir été stoppée due à des permissions insuffisantes
 d’accès au dossier parent, auquel cas essayez de changer la commande suivante en conséquence.
Faire
# /sbin/restorecon -v [...]

*****  Le greffon catchall (1.49 de confiance) suggère   *********************

Si vous pensez que sendmail devrait être autorisé à accéder append sur [...] file par défaut.
Alors vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet accès.
Faire
autoriser cet accès pour le moment en exécutant :
# ausearch -c "sendmail" --raw | audit2allow -M my-sendmail
# semodule -X 300 -i my-sendmail.pp


Informations complémentaires :
Contexte source               system_u:system_r:sendmail_t:s0
Contexte cible                unconfined_u:object_r:httpd_sys_rw_content_t:s0
Objets du contexte            [...]
                              [ file ]
Source                        sendmail
Chemin de la source           sendmail
Port                          <Unknown>
Hôte                          [...]
Paquets RPM source            postfix-3.5.8-4.el8.x86_64
Paquets RPM cible             
Stratégie RPM SELinux         selinux-policy-targeted-3.14.3-117.el8_8.2.noarch
Stratégie locale RPM          selinux-policy-targeted-3.14.3-117.el8_8.2.noarch
Selinux activé                True
Type de stratégie             targeted
Mode strict                   Enforcing
Nom de l'hôte                 [...]
Plateforme                    Linux [...] 4.18.0-477.21.1.el8_8.x86_64
                              #1 SMP Tue Aug 8 21:30:09 UTC 2023 x86_64 x86_64
Compteur d'alertes            15
Première alerte               2023-08-29 14:07:11 UTC
Dernière alerte               2023-08-30 00:07:22 UTC
ID local                      6a8c3b42-9fa6-4172-9c4f-cfd9c7e3e082

Messages d'audit bruts
type=AVC msg=audit(1693354042.110:846): avc:  denied  { append } for  pid=50039 comm="sendmail" path="[...]" dev="vdc1" ino=269291807 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:httpd_sys_rw_content_t:s0 tclass=file permissive=0


type=AVC msg=audit(1693354042.110:846): avc:  denied  { read write } for  pid=50039 comm="sendmail" path="[...]" dev="vdc1" ino=269291780 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:httpd_sys_rw_content_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1693354042.110:846): arch=x86_64 syscall=execve success=yes exit=0 a0=560a775044c0 a1=560a775045a0 a2=560a775021a0 a3=0 items=0 ppid=50026 pid=50039 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm=sendmail exe=/usr/sbin/sendmail.postfix subj=system_u:system_r:sendmail_t:s0 key=(null)

Hash: sendmail,sendmail_t,httpd_sys_rw_content_t,file,append

Ici, vous pouvez constater que deux solutions sont proposé à l’administrateur système. L’une consiste à exécuter restorecon, l’autre à utiliser audit2allow.

SE Boolean

Si la distribution fait un choix d’autorité sur la politique SELinux adopté par votre système, elle propose aussi certaines options à cette politique via l’activation ou désactivation de politique spécifique. Par exemple, par défaut il n’est pas possible à httpd d’envoyer un mail. Cela permet d’éviter les relais de SPAM en cas de vulnérabilité d’une application web et cela convient très bien si votre site n’a pas besoin de cette fonctionnalité. Mais si votre site nécessite une telle fonction, alors elle peut être activée via les booléens SELinux. Pour exemple, il suffit de lancer la commande setsebool httpd_can_sendmail=on pour permettre à httpd d’envoyer un mail.

La liste des booléens disponibles est accessible via la commande getsebool -a.

Commande chcon

La commande chcon permet de modifier le contexte d’un fichier sans modifier la politique SELinux générale. Par exemple, si je souhaite que le fichier /data/images/logo.png soit accessible par le service httpd sans pour autant faire en sorte que systématiquement les images de /data/images soit accessible, je peux utiliser la commande chcon -t httpd_sys_content_t /data/images/logo.png. Seul le fichier logo.png sera accessible à httpd car lui seul aura le context SELinux permettant à httpd d’y acceder.

Commandes semanage / restorecon

Si les deux commandes sont indépendantes, combinées, elles permettent de régler le cas le plus courant que nous puissions rencontrer avec SELinux qui est la relocalisation des datas. En effet, il n’est pas rare que nous voulions relocaliser les données dans un espace autre que /var/${service}/... par exemple, un service web peut être relocaliser de /var/www vers /data/htdocs. Lors d’une telle opération, nous allons combiner les commandes semanage et restorecon.

• semanage va permettre de redéfinir, dans la politique SELinux du système, le contexte d’un répertoire
• restorecon va permettre de restaurer les contextes de fichier tel que défini dans la politique SELinux.

Par exemple, si je veux relocaliser /var/www vers /data/htdocs. Je vais d’abord utiliser semanage pour dire que l’ensemble des fichiers dans le repertoire /data/htdocs est de type web avec la commande

bash-4.1$ semanage fcontext -a -t httpd_sys_content_t "/data/htdocs(/.*)?"

A présent, tout nouveau fichier dans /data/htdocs sera considéré comme ayant le context httpd_sys_content_t.

Maintenant, je modifie les fichiers existant pour qu’ils correspondent à la nouvelle politique SELinux

bash-4.1$ restorecon -R -v /data/htdocs

Commandes ausearch / audit2allow / semodule

La dernière commande que nous allons étudier est la commande audit2allow. A priori, elle n’est nécessaire que dans des cas très spécifique et plutôt lié au développement de nouvelles applications ou alors au packaging. Cette commande permet, à partir du /var/log/audit/audit.log de généré une toute nouvelle politique SELinux.

Cette génération se divise en trois phases :

• ausearch: la commande ausearch -c "service" --raw va permettre de lister les différents context auquel service à tenter d’accéder.
• audit2allow: à partir de l’output de ausearch, audit2allow va créer un nouveau fichier de politique SELinux permettant au service d’accéder aux contextes
• semodule : va permettre d’activer cette nouvelle politique

bash-4.1$ ausearch -c "sendmail" --raw | audit2allow -M my-sendmail
# Cette commande va créer deux fichiers my-sendmail.pp et my-sendmail.te.
bash-4.1$ semodule -X 300 -i my-sendmail.pp
# Cette commande va activer la nouvelle politique my-sendmail.pp

Conclusion

En résumé, SELinux est une fonctionnalité de sécurité avancée pour les systèmes Linux, qui renforce la sécurité en appliquant des contrôles d’accès obligatoires basés sur des règles de sécurité et des étiquettes de sécurité. Cela contribue à réduire les risques associés aux failles logicielles et aux attaques en isolant davantage les processus et en restreignant leurs capacités.