LINUX:SELinux-Méthode de première mise en route
But
Je ne conseille pas de suivre aveuglément les conseils données par Cockpit ou les messages du service "setroubleshootd.service". Je présente ici l'approche que j'ai utilisée. Au premier démarrage de SELinux, on est submergé d'alertes. On va procéder par débroussaillage successif.
Préliminaire
Il faut procéder à une configuration préliminaire:
- Désactiver l'envoi de messages électroniques du service "setroubleshootd.service" en mettant en commentaire (ligne préfixée par le caractère "#") les adresses email de sa configuration
- Placer SELinux en mode permissif
- Redémarrer de système avec l'option de relabélisation du "Context" de tous les fichiers du système (voir le paragraphe sur la Première activation)
- Lors de la découverte de SELinux, travailler sur un système si possible non en production afin de gêner un minimum de personnes.
Fcontext
J'ai l'habitude de placer les données d'applications dans un répertoire personnalisé. Cette configuration me permet de faciliter les sauvegardes, de ne pas être limité par l'espace disque et de pouvoir les déplacer comme on veut. Le fait de ne pas les laisser à l'emplacement défini par défaut, habituellement sous l'arborescence "/var", engendre une foule d'alertes dès que les applications concernées veulent accéder aux données. Il faut bien sûr connaitre son système et les changements auxquels on a procédé.
Voici un premier exemple:
Normalement, les sites Web utilisés par le service Httpd, se trouvent sous l'arborescence "/var/www" qui a le Context de Type "httpd_sys_content_t".
On peut le vérifier par la commande:
matchpathcon /var/www
qui donne:
/var/www system_u:object_r:httpd_sys_content_t:s0
ou par
ls -Z1 /var | grep www
qui donne:
system_u:object_r:httpd_sys_content_t:s0 www
Pour ma part, je les place sous le répertoire "/application/web". Il faut donc que je procède à une relabélisation de cet espace.
On exécute les deux commandes suivantes:
semanage fcontext -a -t httpd_sys_content_t '/application/web(/.*)?' restorecon -RFv /application/web/
De même, les images et autres documents par exemple PDF, prennent beaucoup de place. Nous les avons placés dans un espace à part "/disk1/documents" qu'il faut aussi adapter:
semanage fcontext -a -t httpd_sys_content_t '/disk1/documents(/.*)?' restorecon -RFv /disk1/documents/
Autres exemples:
- L'application GeneWeb comporte deux exécutables lancés sous le contexte de Httpd. On a procédé à la relabélisation suivante:
semanage fcontext -a -t httpd_exec_t '/application/web/geneweb/gw/gwd' semanage fcontext -a -t httpd_exec_t '/application/web/geneweb/gw/gwsetup' restorecon -RFv /application/web/geneweb/gw/
- On utilise BackupPC pour nos sauvegardes. L'espace de sauvegarde se trouve par défaut sous l'arborescence "/var/lib/BackupPC" avec un Context de Type "httpd_var_lib_t". Or on le place dans le répertoire "/disk2/backuppc". On adapte:
semanage fcontext -a -t httpd_var_lib_t '/disk2/backuppc(/.*)?' restorecon -RFv /disk2/backuppc/
- On utilise le gestionnaire de base de données MariaDB (équivalent à MySQL). La base de données est placée par défaut dans le répertoire "/var/lib/mysql" avec un Context de Type "mysqld_db_t". Or on la place dans le répertoire "/application/mysql" et le dump dans le répertoire "/application/mysql.dump". On adapte:
semanage fcontext -a -t mysqld_db_t '/application/mysql(/.*)?' restorecon -RFv /application/mysql/ semanage fcontext -a -t mysqld_db_t '/application/mysql.dump(/.*)?' restorecon -RFv /application/mysql.dump/
- Pour le PostOffice au format "maildir" géré par Dovecot, les boîtes de messages électroniques des utilisateurs sur le serveur sont placées sous le répertoire "/application/vmail". En analysant les Fcontext repris dans les fichiers du répertoire "/etc/selinux//targeted/contexts/files", spécialement le fichier "file_contexts.homedirs", on recherche les répertoires contenant "maildir" ou "Maildir", on y trouve systématiquement le Context de Type "mail_home_rw_t". On l'adapte en conséquence:
semanage fcontext -a -t mail_home_rw_t '/application/vmail(/.*)?' restorecon -RFv /application/vmail/
- Nous avons développé plusieurs scripts qui sont exploités par le service "crond.service" au travers du fichier "/etc/crontab". Ils utilisent des fichiers de données locaux. Nous les avons regroupés sous le répertoire "/application/cron", un répertoire par application. Je n'avais de piste précise; après exploration, j'ai opté pour le Type "system_cron_spool_t" qui est celui du répertoire "/etc/cron.d"; un autre est peut-être plus adapté:
semanage fcontext -a -t system_cron_spool_t '/application/cron(/.*)?' restorecon -RFv /application/cron/
- Pour l'utilisation de Nagios, nous avons développé quelques scripts qui sont utilisés par le service "nrpe.service". Nous les avons placés sous le répertoire "/application/nrpe". Or les "plugins" de Nagios se situent dans le répertoire "/usr/lib64/nagios/plugins" qui ont le Context de Type "nagios_unconfined_plugin_exec_t". On s'adapte:
semanage fcontext -a -t nagios_unconfined_plugin_exec_t '/application/nrpe(/.*)?' restorecon -Rv /application/nrpe/
Maintenant que le gros des problèmes sont résolus, on nettoie toutes les alertes reprises dans l'interface de SELINUX sous Cockpit avant de passer à la suite. Et on peut réactiver d'envoi de mails via le service "setroubleshootd.service".
Boolean
Cet aspect est a considérer en parallèle avec le suivant car il peut résoudre de nombreux problèmes que l'on résoudrait grâce à une foule de règles.
La seconde étape consiste à analyser l'impact des différents Boolean. Nous activons ceux qui nous semblent pertinents. Par après, quand tous les problèmes sont résolus, peut tester leur nécessité en les désactivant. Il est encore temps, dans le cas contraire, de les réactiver. Cette action est immédiat. De même si certains Boolean sont activés et que manifestement on n'utilise pas cette fonctionnalité, on peut les désactiver.
Voici quelques exemples désactivés:
- virt_sandbox_use_all_caps: Non utilisé
- virt_use_nfs: NFS n'est pas utilisé
- httpd_can_network_connect: Au départ je l'ai activé mais dans les faits, le daemon HTTPD n'effectuait aucune connexion TCP (HTTP) vers d'autres machines
- mysql_connect_any: De même, il a été activé mais au final, il s'est avéré inutile. Le daemon MariaDB n'a pas besoin d'effectuer des connexions TCP.
- mysql_connect_http: De même, il a été activé mais au final, il s'est avéré inutile. Le daemon MariaDB n'a pas besoin d'effectuer des connexions TCP (HTTP).
Il y en a bien d'autres qu'il faut désactiver et qui le sont par défaut.
Voici quelques exemples que j'ai dû activer:
- samba_enable_home_dirs: J'utilise Samba et la facilité des espaces Home des utilisateurs.
- use_samba_home_dirs: Idem que le précédent
- samba_export_all_ro: Nécessaire pour lire les fichiers via Samba
- samba_export_all_rw: Nécessaire pour écrire dans les fichiers via Samba
- nis_enabled: J'utilise le fichier "/etc/hosts" en plus du DNS pour la résolution de nom de machines. Il s'est avéré nécessaire.
- domain_can_mmap_files: Ce Boolean semble utile car il revient fréquemment dans les conseils prodigués lors de la création de modules. Je ne l'ai pas activé par sécurité.
- rsync_export_all_ro et rsync_full_access: J'utilise Rsyncd au travers de Backuppc et des sauvegardes.
- httpd_unified: Il permet de se simplifier la vie au niveau des types de permissions d'accès de chaque fichier des sites Web.
- httpd_can_sendmail: Nombre de sites ont possède la possibilité d'envoyer des mails.
Module
Nous arrivons à la dernière phase.
On passe en revue chaque application ou partie majeure en revue à tour de rôle. On traite seulement des alertes déclenchées en regard de cette application. Quand toutes les alertes d'une application ont été résolue via la création et l'installation d'un module spécifique, on passe à l'application suivante.
Pour y arriver, on suit la méthode exposée dans l'article sur Création de sources; on compile et ensuite on installe le module.
Au final, on n'a plus d'alerte courantes. Mais plusieurs applications ne s'exécutent que périodiquement. C'est le cas des applications s'activant via le service "crond.service" tel "logwatch" et aussi des services de Systemd du "timers.target" tel "logrotate". Il faut donc laisser le système tourner quelques jours, au moins une semaine et repérer les alertes éventuelles. Certaines applications ne sont lancées que tous les mois ou plus. Dans la mesure du possible, on essaie de raccourcir cet intervalle à une journée. On le remet à sa valeur d'origine par après.
Même pour un système qui semble stable depuis longtemps en mode SELinux actif, une alerte de temps en temps arrive suite par exemple à une mise à jour d'un logiciel ou suite à une action rare. On la règle de la même façon.
Activation
Quand votre système ne présente plus d'alerte après une semaine ou plus, on peut passer à la phase d'activation de SELinux. On modifie le fichier "/etc/selinux/config"; on y remplace la valeur "permissive" par "enforcing" pour l'option "SELINUX". On peut ensuite exécuter la commande:
setenforce 1
si on ne veut pas redémarrer la machine.
Vérification
Lors des trois derniers points, il faut vérifier en profondeur que chaque application fonctionne correctement.
Il faut noter qu'il existe des règles qui annulent l'apparition d'alertes: "dontaudit". Dans ce cas, elles se manifestent indirectement par des blocages sans alerte pour l'application concernée quand le système SELinux est activé en mode renforcé. D'où la nécessité de vérifier leur bon fonctionnement après activation de SELinux. Ceci m'est arrivé lors de la création d'un module SELinux pour une application personnelle mais jamais pour les applications provenant de paquets inclus dans la distribution.
Une solution de dernier recours consiste à désactiver globalement ces règles "dontaudit" par la commande:
semodule -DB
Mais ATTENTION, il faut prendre quelques précautions. En effet, dès ce moment, vous serez submergé d'alertes.
- Avant de passer à cette état, désactivez l'envoi de mail via le service "setroubleshootd.service". Si vous ne le faites pas vous recevrez en peu de temps des milliers de mails. L'arrêt du serveur de messagerie ne sert à rien; ce problème ne sera que reporté à plus tard.
- Travaillez si possible sur une machine de test ou une machine n'ayant que peu d'impact pour l'ensemble de votre réseau et sur vos utilisateurs.
- Lancez cette commande ("semodule -DB") et après quelques minutes revenez à l'état d'origine ("semodule -B")
- Analysez les alertes générées pendant ce laps de temps et essayer de repérer les services souvent concernés.
- Arrêtez temporairement ces services s'ils ne concernent pas le blocage. Le nombre d'alertes en sera fortement diminué.
A ce stade, vous pouvez déactiver globalement les clauses de "dontaudit" et travailler sur votre application ayant des blocages à votre aise. Le nombre de messages d'alertes sera nettement plus réduit et vous aurez facile pour repérer les alertes qui vous intéressent et donc pour résoudre votre problème.
Le problème résolu, revenez à l'état normal avec la commande:
semodule -B
Et revenez à votre configuration normale.
Exemples
Voici quelques exemples de fichiers de ".te". Ils sont souvent très réduits ou à la structure répétitive.