5.3. Correction des dénis SELinux analysés
Dans la plupart des cas, les suggestions fournies par l'outil sealert vous indiquent comment résoudre les problèmes liés à la politique SELinux. Voir Analyse des messages de refus SELinux pour savoir comment utiliser sealert pour analyser les refus SELinux.
Soyez prudent lorsque l'outil suggère d'utiliser l'outil audit2allow pour les changements de configuration. Vous ne devez pas utiliser audit2allow pour générer un module de politique locale comme première option lorsque vous constatez un refus SELinux. Le dépannage doit commencer par une vérification de l'existence d'un problème d'étiquetage. Le deuxième cas le plus fréquent est que vous avez modifié la configuration d'un processus et que vous avez oublié d'en informer SELinux.
Problèmes d'étiquetage
Une cause fréquente de problèmes d'étiquetage est l'utilisation d'un répertoire non standard pour un service. Par exemple, au lieu d'utiliser /var/www/html/ pour un site Web, un administrateur pourrait vouloir utiliser /srv/myweb/. Sur Red Hat Enterprise Linux, le répertoire /srv est étiqueté avec le type var_t. Les fichiers et les répertoires créés dans /srv héritent de ce type. De même, les objets nouvellement créés dans les répertoires de premier niveau, tels que /myserver, peuvent être étiquetés avec le type default_t. SELinux empêche le serveur HTTP Apache (httpd) d'accéder à ces deux types. Pour autoriser l'accès, SELinux doit savoir que les fichiers de /srv/myweb/ doivent être accessibles par httpd:
# semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"
La commande semanage ajoute le contexte du répertoire /srv/myweb/ et de tous les fichiers et répertoires qu'il contient à la configuration SELinux du contexte des fichiers. L'utilitaire semanage ne modifie pas le contexte. En tant que super-utilisateur, utilisez l'utilitaire restorecon pour appliquer les modifications :
# restorecon -R -v /srv/mywebContexte incorrect
L'utilitaire matchpathcon vérifie le contexte d'un chemin de fichier et le compare à l'étiquette par défaut pour ce chemin. L'exemple suivant illustre l'utilisation de matchpathcon sur un répertoire contenant des fichiers mal étiquetés :
$ matchpathcon -V /var/www/html/*
/var/www/html/index.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/page1.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
Dans cet exemple, les fichiers index.html et page1.html sont étiquetés avec le type user_home_t. Ce type est utilisé pour les fichiers se trouvant dans les répertoires personnels des utilisateurs. L'utilisation de la commande mv pour déplacer des fichiers à partir de votre répertoire personnel peut entraîner l'étiquetage des fichiers avec le type user_home_t. Ce type de fichier ne devrait pas exister en dehors des répertoires personnels. Utilisez l'utilitaire restorecon pour rétablir le type correct de ces fichiers :
# restorecon -v /var/www/html/index.html
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0
Pour restaurer le contexte de tous les fichiers d'un répertoire, utilisez l'option -R:
# restorecon -R -v /var/www/html/
restorecon reset /var/www/html/page1.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0Applications confinées configurées de manière non standard
Les services peuvent être exécutés de différentes manières. Pour tenir compte de cela, vous devez spécifier comment vous exécutez vos services. Pour ce faire, vous pouvez utiliser les booléens SELinux qui permettent de modifier certaines parties de la politique SELinux au moment de l'exécution. Cela permet d'effectuer des changements, tels que l'accès des services aux volumes NFS, sans recharger ou recompiler la politique SELinux. Par ailleurs, l'exécution de services sur des numéros de port autres que ceux par défaut nécessite la mise à jour de la configuration de la politique à l'aide de la commande semanage.
Par exemple, pour permettre au serveur HTTP Apache de communiquer avec MariaDB, activez le booléen httpd_can_network_connect_db:
# setsebool -P httpd_can_network_connect_db on
Notez que l'option -P rend le paramètre persistant à travers les redémarrages du système.
Si l'accès est refusé pour un service particulier, utilisez les utilitaires getsebool et grep pour voir s'il existe des booléens permettant d'autoriser l'accès. Par exemple, utilisez la commande getsebool -a | grep ftp pour rechercher les booléens relatifs à FTP :
$ getsebool -a | grep ftp
ftpd_anon_write --> off
ftpd_full_access --> off
ftpd_use_cifs --> off
ftpd_use_nfs --> off
ftpd_connect_db --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> off
Pour obtenir une liste de booléens et savoir s'ils sont activés ou désactivés, utilisez la commande getsebool -a. Pour obtenir une liste de booléens avec leur signification et savoir s'ils sont activés ou désactivés, installez le paquet selinux-policy-devel et utilisez la commande semanage boolean -l en tant que root.
Numéros de port
En fonction de la configuration de la politique, les services ne peuvent être autorisés à fonctionner que sur certains numéros de port. Si vous tentez de modifier le port sur lequel un service s'exécute sans modifier la stratégie, le service risque de ne pas démarrer. Par exemple, exécutez la commande semanage port -l | grep http en tant que super-utilisateur pour dresser la liste des ports liés à http:
# semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989
Le type de port http_port_t définit les ports sur lesquels le serveur HTTP Apache peut écouter, qui dans ce cas sont les ports TCP 80, 443, 488, 8008, 8009 et 8443. Si un administrateur configure httpd.conf de sorte que httpd écoute sur le port 9876 (Listen 9876), mais que la stratégie n'est pas mise à jour pour refléter ce changement, la commande suivante échoue :
# systemctl start httpd.service Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details. # systemctl status httpd.service httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) Active: failed (Result: exit-code) since Thu 2013-08-15 09:57:05 CEST; 59s ago Process: 16874 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=0/SUCCESS) Process: 16870 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Un message de refus SELinux similaire au suivant est enregistré à l'adresse /var/log/audit/audit.log:
type=AVC msg=audit(1225948455.061:294): avc: denied { name_bind } for pid=4997 comm="httpd" src=9876 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Pour permettre à httpd d'écouter sur un port qui n'est pas répertorié pour le type de port http_port_t, utilisez la commande semanage port pour attribuer une étiquette différente au port :
# semanage port -a -t http_port_t -p tcp 9876
L'option -a ajoute un nouvel enregistrement, l'option -t définit un type et l'option -p définit un protocole. Le dernier argument est le numéro de port à ajouter.
Cas particuliers, applications évolutives ou défectueuses et systèmes compromis
Les applications peuvent contenir des bogues, ce qui conduit SELinux à refuser l'accès. De plus, les règles SELinux évoluent - SELinux peut ne pas avoir vu une application fonctionner d'une certaine manière, ce qui peut entraîner un refus d'accès, même si l'application fonctionne comme prévu. Par exemple, si une nouvelle version de PostgreSQL est publiée, elle peut effectuer des actions que la politique actuelle ne prend pas en compte, ce qui entraîne un refus d'accès, alors que l'accès devrait être autorisé.
Dans ce cas, lorsque l'accès est refusé, utilisez l'utilitaire audit2allow pour créer un module de politique personnalisé afin d'autoriser l'accès. Vous pouvez signaler les règles manquantes dans la politique SELinux dans le fichier Red Hat Bugzilla. Pour Red Hat Enterprise Linux 9, créez des bogues contre le produit Red Hat Enterprise Linux 9 et sélectionnez le composant selinux-policy. Incluez la sortie des commandes audit2allow -w -a et audit2allow -a dans ces rapports de bogue.
Si une application demande des privilèges de sécurité importants, cela peut être un signal que l'application est compromise. Utilisez des outils de détection d'intrusion pour inspecter ces comportements suspects.
La page Solution Engine sur le portail client de Red Hat peut également fournir des conseils sous la forme d'un article contenant une solution possible pour le même problème ou un problème très similaire que vous rencontrez. Sélectionnez le produit et la version appropriés et utilisez les mots-clés liés à SELinux, tels que selinux ou avc, ainsi que le nom de votre service ou application bloqué(e), par exemple : selinux samba.
