Vérifiez les labels avant d'accuser SELinux

Quand une application casse sur un hôte avec SELinux en enforcing, le réflexe de beaucoup d'équipes est de passer SELinux en permissive et de continuer. Nous le gardons en enforcing sur chaque hôte que nous exploitons, et d'expérience la cause est en général bien plus petite que ce que le réflexe suggère : un fichier qui porte le mauvais label. Cet article montre comment le trouver vite, le corriger correctement, et éviter de vous enfermer dehors pendant que vous le faites.

Ce qu'est un label, et comment il se dérègle

SELinux prend ses décisions à partir de labels. Chaque fichier et chaque processus porte un contexte de sécurité, et la politique dit quels types de processus peuvent faire quoi sur quels types de fichiers. La politique dit aussi quel label chaque chemin devrait avoir : le contenu de /var/www devrait être httpd_sys_content_t, un exécutable sous /usr/bin devrait être bin_t, et ainsi de suite. Ces labels attendus sont les règles de file context.

Un fichier reçoit son label à sa création, normalement hérité de son répertoire parent ou fixé par une règle de la politique. Cela fonctionne bien jusqu'à ce que des fichiers arrivent par une voie inhabituelle :

• mv conserve le label d'origine, donc un fichier créé dans un répertoire personnel et déplacé dans une racine web dit toujours qu'il appartient à un répertoire personnel.
• Des archives décompressées sans attributs SELinux, ou restaurées depuis un backup qui ne les a pas conservés, reçoivent ce que le répertoire cible leur donne.
• Du contenu placé dans un emplacement personnalisé, comme /srv/app, reçoit un label générique parce que la politique n'a pas encore de règle pour ce chemin.

Dans chacun de ces cas, la politique va très bien. Le fichier porte simplement le mauvais label, et le processus qui en a besoin est refusé.

Lisez d'abord le refus

Avant de changer quoi que ce soit, lisez ce que SELinux a réellement refusé :

ausearch -m AVC -ts recent

Chaque refus nomme le type de processus (scontext), le type de cible (tcontext), la classe d'objet et la permission. Si le type de cible semble faux pour ce fichier (un serveur web à qui l'on refuse de lire quelque chose labellisé user_home_t, par exemple), vous regardez presque certainement un problème de labellisation, pas une lacune de la politique.

Comparez ce qui est là avec ce qui devrait l'être

Trois commandes répondent directement à la question :

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

restorecon -n ne change rien. Il signale seulement la différence entre le label actuel et le label attendu, ce qui en fait l'outil d'audit parfait. Exécutez-le sur une arborescence entière après une installation, une restauration ou une migration :

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Un résultat vide signifie que chaque fichier sous ces chemins porte le label que la politique attend. Toute ligne dans la sortie est un fichier qui ne le porte pas, et cette liste est en général courte et très parlante. Nous exécutons ce type de vérification sur les nouvelles constructions par routine, et nos modèles d'installation relabellisent les chemins critiques dans leur étape post-install, pour qu'un nouvel hôte commence sa vie avec des labels corrects avant que quiconque ne s'y connecte.

Corrigez-le de la bonne façon

Pour un fichier qui a simplement le mauvais label, relabellisez-le selon ce que la politique attend :

restorecon -Rv /path

Pour un emplacement personnalisé que la politique ne connaît pas, enseignez d'abord la règle à la politique, puis relabellisez, pour que le correctif survive au prochain relabel complet :

semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?"
restorecon -Rv /srv/app

chcon change aussi les labels, mais seulement jusqu'au prochain relabel, après quoi le problème revient. Utilisez-le pour des expériences, pas pour des correctifs.

Si les labels sont justes et que le refus porte sur un comportement, vérifiez les booléens avant d'écrire de la politique. Beaucoup de besoins courants, comme un serveur web qui ouvre des connexions réseau sortantes, sont un seul interrupteur :

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Méfiez-vous d'audit2allow

audit2allow lit les refus et écrit un module de politique qui les autorise. Il produira toujours quelque chose qui fonctionne, et c'est exactement le danger. Si la vraie cause est un fichier mal labellisé, le module généré accorde une permission large pour faire disparaître le symptôme, et chaque autre fichier et processus de ce type hérite de la politique affaiblie. Lisez ce qu'il propose. Une règle qui permet à un domaine de transiter vers un domaine très privilégié, ou de lire tout ce qui est d'un type courant, est un indice fort que le label est faux et que le module est le mauvais correctif. Les modules personnalisés sont parfois corrects, pour du logiciel maison sans politique propre, mais ils doivent être la dernière étape, pas la première.

Passez en enforcing sans danger sur un hôte distant

Faire passer une machine distante de permissive à enforcing est l'un de ces changements qui peuvent couper votre propre session si quelque chose est encore mal labellisé. Armez d'abord un filet de sécurité, pour que l'hôte revienne de lui-même si vous perdez l'accès :

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

systemd déclenche le timer que votre session survive ou non. Annulez-le seulement après qu'une toute nouvelle connexion a réussi. Le même schéma fonctionne pour les changements de firewall, de SSH et de routage sur une machine jusqu'à laquelle vous ne pouvez pas marcher.

Une courte liste de contrôle

• Exécutez restorecon -Rnv sur les chemins système après chaque installation, restauration ou migration.
• Lisez le refus AVC et comparez ls -Z avec matchpathcon avant de changer la politique.
• Utilisez semanage fcontext plus restorecon pour les chemins personnalisés, pas chcon.
• Vérifiez les booléens avant d'écrire un module.
• Traitez la sortie d'audit2allow comme une question, pas comme une réponse.
• Ne basculez jamais un hôte distant en enforcing sans un retour chronométré.

Si un éditeur d'application vous a dit de désactiver SELinux et que vous préféreriez ne pas le faire, nous vous aiderons volontiers à trouver le correctif précis. Parler à un ingénieur

Related

Voir aussi : Le hardening baseline sur chaque hôte · Réponse d'urgence aux vulnérabilités, le jour même