Pourquoi déplacer un certificat VPN casse son étiquette SELinux

Les certificats peuvent se trouver dans le bon répertoire avec un mode lisible et une propriété root, et le service peut malgré tout signaler qu’il ne peut pas ouvrir le fichier. Sur un système SELinux, cette combinaison désigne un mécanisme précis et non les permissions. L’étiquette a voyagé avec le fichier, car un renommage ne crée pas un nouvel objet. L’inode a conservé le contexte de sécurité qu’il avait à l’ancien chemin, et la stratégie du nouveau chemin n’a jamais eu l’occasion d’attribuer le sien.

Ce qu’un renommage fait réellement à une étiquette

Un fichier porte son contexte SELinux comme des données d’attribut attachées à l’inode. Un renommage au sein d’un même système de fichiers modifie l’entrée de répertoire et rien d’autre, ce qui est rapide et atomique, et c’est la raison pour laquelle le contexte survit au déplacement. Aucune stratégie n’est consultée, aucune valeur par défaut n’est appliquée et aucun avertissement n’est imprimé.

La copie se comporte autrement. Une copie crée un nouvel inode dans le répertoire de destination, et la stratégie attribue un contexte d’après le type de ce répertoire, si bien qu’un certificat copié finit généralement avec la bonne étiquette tandis qu’un certificat déplacé reste mal étiqueté. Cette seule différence explique la majeure partie de la confusion dans cette catégorie de tickets.

Les déplacements entre systèmes de fichiers retombent sur la sémantique de copie, donc la même commande peut se comporter différemment sur deux machines selon que /etc vit sur son propre volume. Vérifiez-le avant de conclure que l’outil n’est pas fiable. Un coup d’œil à la table des montages vous dit quel type de déplacement vous avez effectué.

Lisez l’étiquette actuelle face à celle attendue

Trois commandes en lecture seule répondent à la question sans rien changer. La première montre ce que le fichier possède maintenant, la deuxième indique ce que la stratégie attend pour ce chemin exact, et la troisième énumère chaque fichier du répertoire dont l’étiquette diffère.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

C’est l’exécution à blanc qu’il faut croire, car elle nomme chaque fichier dont le contexte s’écarte de la stratégie tout en laissant le système intact. Si le certificat apparaît dans cette liste, vous avez trouvé l’écart entre ce que le chemin signifie et ce que le fichier prétend. S’il n’y apparaît pas, l’étiquette est déjà celle que veut la stratégie et votre temps appartient ailleurs.

Corrélez ensuite la différence avec un refus réel. Une discordance est une preuve d’étiquette incorrecte, non la preuve que le service a échoué à cause d’elle, et un correctif appliqué sans refus correspondant dans le journal est une conjecture avec des étapes en plus.

Restaurez la correspondance au lieu d’inventer une exception

Pour un emplacement standard, la stratégie associe déjà le chemin, donc restorecon l’applique et le travail est fait. Gardez la portée sur le répertoire que vous réparez ; réétiqueter tout le système de fichiers est lent, perturbateur et enterre l’erreur d’origine sous un changement très important.

Pour un répertoire personnalisé, l’ordre compte, et l’inverser produit une commande qui signale un succès sans rien changer. La correspondance appartient à la stratégie, le réétiquetage appartient à la fin, et l’exécution à blanc appartient avant les deux. Sauter cette dernière partie est la façon dont un chemin qui n’a jamais été faux finit quand même réétiqueté.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon applique une correspondance ; il ne peut pas en inventer une. Si aucune règle ne décrit le chemin, il n’y a rien à restaurer, et c’est pourquoi la correspondance persistante doit exister avant le réétiquetage. Notez quelle configuration possède cette correspondance, car sinon un déplacement ultérieur, une mise à jour de paquet ou un réétiquetage recréent la panne et la personne suivante repart de zéro.

Pourquoi chcon n’est pas la solution

chcon écrit un contexte directement sur le fichier. Il prend effet immédiatement et c’est l’option la moins durable disponible, car un réétiquetage du système de fichiers réapplique la stratégie et écarte les modifications manuelles sans demander. Le fichier semble réparé et la réparation a une date d’expiration que personne n’a écrite. Ce que vous voulez à la place, c’est une règle qui décrit le chemin, afin que chaque fichier qui y arrive reçoive automatiquement le même traitement.

Pire, cela enseigne la mauvaise leçon : la correspondance sous-jacente manque toujours, donc la panne revient des semaines plus tard sans déclencheur évident et sans mémoire du contournement. N’utilisez chcon que comme expérience temporaire pour confirmer une hypothèse, puis remplacez-le par une correspondance qui survit au réétiquetage suivant, et vérifiez que le remplacement est réellement en place.

Quand l’étiquette est correcte et que l’accès échoue toujours

Commencez par les répertoires parents. Le droit de traversée est vérifié sur chaque composant du chemin, donc un certificat correctement étiqueté dans un répertoire où le service ne peut pas entrer reste illisible. SELinux et la permission ordinaire doivent tous deux autoriser chaque étape, et corriger l’un ne corrige pas l’autre.

Vérifiez ensuite l’identité du processus et le bac à sable propre au service. Une unité dotée d’un bac à sable restrictif peut refuser l’accès à un fichier que la stratégie autoriserait volontiers, et à la lecture de la ligne de journal les deux causes se ressemblent. Confirmez quel processus demande réellement, et non celui que vous supposez demander.

N’oubliez pas que les règles dontaudit peuvent supprimer les messages de refus, donc un journal d’audit vide est une preuve faible et non une démonstration. Si la stratégie semble correcte et que l’accès échoue toujours, enquêtez avant de générer un module d’autorisation large, et ne désactivez pas SELinux pour faire disparaître le symptôme. Les deux raccourcis produisent un système qui semble fonctionner et une posture de sécurité que personne ne peut décrire. Une courte enquête vaut mieux que l’une ou l’autre.