Root dans un terminal, refusé sous SELinux : pourquoi le hook échoue

Vous exécutez le script up en root, il se termine, et le même script échoue lorsque le service l’appelle. Rien n’a changé dans les permissions du fichier, donc l’étape suivante naturelle consiste à les assouplir de nouveau, ce qui ne corrige rien. Sur un hôte SELinux, le facteur décisif n’est souvent pas l’identité du processus mais le domaine dans lequel il s’exécute, et root à l’intérieur d’un domaine confiné reste confiné.

La même commande, deux domaines de sécurité différents

L’application de types évalue ensemble le domaine source, l’étiquette cible et l’opération demandée. Votre session de terminal s’exécute dans un domaine non confiné ou administratif, et le démon s’exécute dans le domaine attribué à son unité. Des commandes identiques produisent donc des décisions différentes, et cette différence est voulue plutôt qu’un défaut de la politique.

C’est pourquoi comparer les deux exécutions n’est utile que si vous comparez leurs contextes. Lancez la même commande depuis le shell et depuis le hook ; la version du shell prouve que le binaire existe et que les arguments sont corrects, mais elle ne prouve rien sur le droit du service à l’exécuter. Lancez-la des deux façons et comparez les domaines, pas seulement les codes de sortie. C’est cette comparaison qui transforme une plainte vague sur les permissions en une question précise sur un domaine et une étiquette.

La forme classique de ce défaut est un assistant qui appelle un outil externe. Le hook lui-même peut être autorisé, tandis que l’outil qu’il invoque porte une étiquette que le domaine du service n’a pas le droit d’exécuter, ou écrit dans un répertoire dont l’étiquette l’interdit.

Lisez l’enregistrement AVC à côté de l’erreur du hook

Un refus AVC nomme les champs qui décident de l’affaire : le contexte source du processus, le contexte cible de l’objet, la classe de l’objet et la permission précise qui a été refusée. Lisez les quatre avant de bâtir une théorie, car un refus sur l’exécution et un refus sur l’écriture appellent des réparations totalement différentes.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Le contexte source devrait correspondre au domaine dans lequel le service s’exécute réellement, et le contexte cible à l’étiquette du fichier ou du répertoire touché par l’opération. Si l’un des deux ne correspond pas à l’erreur que vous suivez, vous lisez un autre événement.

Notez la version de la politique et le chemin exact de l’exécutable à côté de l’enregistrement. Un nom de domaine qui apparaît dans la politique d’une distribution est une preuve concernant cette installation, pas la garantie qu’une autre compilation fournit les mêmes règles. C’est ce contexte qui permet à quelqu’un d’autre de reproduire votre conclusion sur son propre hôte. Sans lui, l’enregistrement se lit comme une anecdote plutôt que comme une preuve.

Étiquette, configuration ou politique : trois réparations

La première réparation est une étiquette qui ne correspond pas à l’emplacement installé du fichier. Un script copié en place avec cp ou écrit par un éditeur peut porter une étiquette par défaut que le domaine du service ne peut pas utiliser, et restaurer le contexte attendu règle cela sans toucher à la politique.

La deuxième est la configuration. La distribution peut offrir un moyen pris en charge d’exécuter l’opération, un répertoire documenté pour l’assistant ou un paquet de politique mis à jour qui l’autorise déjà. Changer votre disposition pour la disposition prise en charge coûte moins cher que d’écrire une politique et survit aux mises à jour.

La troisième est une règle réellement absente, et elle devrait être le dernier recours. Générez un candidat avec les outils d’audit, lisez ce qu’il autorise réellement, restreignez-le à l’opération et au domaine que vous avez observés, et faites-le relire par quelqu’un d’autre avant qu’il n’approche de la production.

Pourquoi un ancien module allow n’est pas la réponse

Les résultats de recherche sur ce défaut sont pleins de modules préconstruits, souvent pour un outil que le hook n’appelle plus. En installer un accorde des permissions qui n’ont peut-être rien à voir avec votre refus, et il laisse la vraie incohérence en place tout en ajoutant un trou permanent.

Il masque aussi la défaillance suivante. Un module qui autorise une large classe d’opérations fera disparaître cette erreur et transformera la suivante en quelque chose de bien plus difficile à attribuer. Retirer le module plus tard est aussi un changement que personne ne veut planifier, donc le raccourci tend à devenir permanent.

La comparaison disciplinée se fait entre le refus que vous pouvez lire et le changement que vous proposez. Le guide de dépannage SELinux de Red Hat place les vérifications d’étiquetage et de configuration avant la politique générée précisément pour cette raison. S’il n’y a pas de refus correspondant dans l’enregistrement, SELinux n’est probablement pas votre problème, et les problèmes de chemin, de bac à sable ou de permissions restent ouverts.