Sur Debian, désactiver complètement SELinux sans redémarrer n’est généralement pas possible : la désactivation totale se décide au démarrage du noyau. En revanche, si SELinux est actif, il est possible de passer immédiatement en mode permissif pour arrêter le blocage des opérations tout en conservant les traces d’audit. La distinction est essentielle, surtout sur Debian, où AppArmor est souvent le mécanisme de sécurité installé par défaut.
L’essentiel à retenir
La commande disponible sans redémarrage modifie le niveau d’application des règles, mais ne désactive pas entièrement SELinux. Avant toute intervention, vérifiez que SELinux est bien actif sur cette installation Debian.
- Vérifier le système : Confirmez que SELinux est actif et que les commandes nécessaires sont installées.
- Basculer à chaud : setenforce 0 passe en mode permissif sans redémarrage.
- Comprendre la limite : Le mode permissif journalise les refus, mais ne les bloque pas.
- Désactiver complètement : L’option selinux=0 s’applique au démarrage suivant.
À retenir : sans redémarrage, il s’agit d’assouplir l’application des règles, pas de désactiver le mécanisme.
SELinux Debian : ce qui peut réellement changer sans redémarrage
SELinux ajoute un contrôle d’accès obligatoire, ou MAC, aux permissions classiques des fichiers et des utilisateurs. Ses règles peuvent limiter un processus même lorsque les permissions Unix lui accordent l’accès. Sur Debian, AppArmor est généralement activé par défaut ; la présence de SELinux dépend donc de l’installation et de la configuration du système.
La désactivation temporaire de SELinux sans redémarrage correspond en pratique au passage en mode permissif. Le noyau continue d’évaluer les règles et d’enregistrer les refus, mais ne bloque plus les actions concernées. Une désactivation complète, elle, empêche SELinux de charger sa politique et nécessite un redémarrage avec une option de démarrage adaptée.
Enforcing, permissif et désactivé : trois états distincts
| État | Effet sur les règles | Redémarrage requis |
|---|---|---|
| Enforcing | Les règles sont appliquées ; les actions interdites sont bloquées et journalisées. | Non pour passer temporairement en permissif. |
| Permissif | Les violations sont enregistrées, mais ne sont pas bloquées. | Non si SELinux est déjà chargé. |
| Désactivé | SELinux ne charge pas sa politique et ne contrôle pas les accès. | Oui, après modification des paramètres de démarrage. |
Cette distinction évite une confusion fréquente : le mode permissif n’est pas une désactivation complète. Il constitue plutôt une configuration runtime SELinux utile pour diagnostiquer un blocage ou tester un changement sans interrompre immédiatement un service.
Vérifier SELinux et les outils disponibles sur Debian
Avant de modifier quoi que ce soit, identifiez le mécanisme réellement actif. La commande getenforce affiche le mode SELinux ; sestatus fournit des informations complémentaires. Si ces commandes sont absentes, SELinux n’est peut-être pas installé, ou les utilitaires nécessaires ne sont pas présents.
Sur une installation minimale, l’outil policycoreutils et les utilitaires SELinux associés peuvent manquer. Vérifiez également AppArmor avec sudo aa-status si cette commande est disponible. Une réponse indiquant que SELinux est désactivé ne signifie pas nécessairement qu’AppArmor l’est aussi : les deux mécanismes sont distincts.
- Contrôler le mode : exécutez getenforce.
- Examiner l’état détaillé : exécutez sestatus.
- Vérifier la disponibilité de setenforce : utilisez command -v setenforce.
- Identifier AppArmor : vérifiez son état séparément avec sudo aa-status.
Interpréter les résultats avant d’agir
Si getenforce renvoie Enforcing, SELinux est actif et applique ses règles. Si le résultat est Permissive, les événements sont audités sans blocage ; si la commande renvoie Disabled, le contrôle SELinux n’est pas actif.
Si la commande est introuvable, ne tentez pas d’appliquer aveuglément une procédure conçue pour RHEL ou Fedora. Dans le cadre de l’administration système Linux, le bon premier geste consiste à confirmer la distribution, les paquets présents et le système de sécurité effectivement chargé.
Passer SELinux en mode permissif sans redémarrage
Lorsque SELinux est chargé et que la commande est disponible, le changement temporaire s’effectue avec les privilèges administrateur. La commande setenforce 0 bascule le système en mode permissif immédiatement ; elle ne désactive pas le suivi des refus et ne modifie pas, à elle seule, la configuration permanente.
Commande : sudo setenforce 0. Vérifiez ensuite le résultat avec getenforce : la réponse attendue est Permissive. Pour revenir à l’application stricte des règles, utilisez sudo setenforce 1, puis confirmez le retour à Enforcing.
Quand utiliser cette bascule temporaire
Le mode permissif peut aider à déterminer si une erreur de service est liée à une règle SELinux. Par exemple, une application qui échoue à lire un fichier peut fonctionner après la bascule ; ce résultat oriente le diagnostic, mais ne corrige ni l’étiquetage du fichier ni la politique à l’origine du refus.
Le piège ici : laisser le système en permissif après le test. Les actions qui auraient été bloquées peuvent alors réussir, même si elles restent consignées. Utilisez cette bascule comme un outil de diagnostic, puis rétablissez l’application des règles ou corrigez la cause précise.
Désactiver complètement SELinux : une opération au prochain démarrage
Un basculement runtime avec setenforce 0 ne peut pas rendre SELinux complètement inactif. Pour demander au noyau de ne pas activer SELinux, il faut ajouter le paramètre selinux=0 à sa ligne de démarrage, puis redémarrer. Cette méthode est distincte du passage en permissif avec enforcing=0.
Sur Debian, la procédure exacte dépend de la manière dont GRUB est configuré. Après sauvegarde de la configuration, ajoutez le paramètre au démarrage du noyau selon la méthode utilisée sur votre système, régénérez la configuration GRUB si nécessaire, puis redémarrez. Modifier uniquement /etc/selinux/config ne change pas l’état courant et ne remplace pas le paramètre du noyau lorsque la désactivation complète est recherchée.
Une désactivation totale réduit la protection apportée par SELinux. Si le problème concerne un service précis, mieux vaut examiner les événements d’audit et corriger le contexte ou la règle concernée plutôt que couper la protection pour toute la machine.
Permissif au démarrage ou SELinux désactivé
Pour démarrer en permissif, le paramètre noyau enforcing=0 demande de ne pas appliquer les règles, tout en conservant SELinux chargé et les événements d’audit. Pour empêcher son activation, selinux=0 demande au noyau de le désactiver. Dans les deux cas, le changement concerne le démarrage et ne se produit pas à chaud.
Les modifications de configuration doivent être planifiées : conservez un accès de secours, vérifiez la ligne de commande du noyau après redémarrage et documentez le retour arrière. Une bascule sans redémarrage reste limitée au mode permissif si SELinux est déjà en fonctionnement.
Diagnostiquer le refus avant de modifier les politiques SELinux
Le mode permissif est utile pour observer, mais les journaux permettent souvent d’identifier le problème sans affaiblir toute la machine. Un refus AVC précise notamment le processus concerné, le type de ressource ciblée et l’opération refusée. Sur Debian, les outils disponibles varient selon les paquets installés.
Si les événements d’audit sont présents, ausearch -m AVC –success no permet de rechercher des refus. L’outil audit2why, lorsqu’il est installé, aide à interpréter leur cause. La suite logique consiste à vérifier le contexte ou le booléen concerné ; la génération d’une règle avec audit2allow doit rester un dernier recours, après examen de l’impact sur la sécurité.
- Repérer le refus : consultez les journaux d’audit et recherchez les événements AVC.
- Identifier la ressource : vérifiez les contextes du processus et du fichier concernés.
- Corriger précisément : ajustez le contexte ou le paramètre adapté plutôt que de désactiver toute la politique.
- Valider le retour sécurisé : repassez en enforcing et testez le service.
Une gestion des politiques SELinux efficace privilégie une correction ciblée et durable. Ainsi, un échec d’accès ne conduit pas automatiquement à une désactivation globale : il devient un indice exploitable pour comprendre la règle en jeu.
Questions fréquentes sur la désactivation de SELinux sous Debian
Peut-on désactiver complètement SELinux sans redémarrer ?
Non. Si SELinux est chargé, setenforce 0 le fait passer en mode permissif sans redémarrage, mais ne le désactive pas complètement. La désactivation complète exige un paramètre de démarrage du noyau, tel que selinux=0, puis un redémarrage.
Que fait exactement la commande setenforce 0 ?
Elle bascule SELinux en mode permissif : les règles sont évaluées et les violations journalisées, mais elles ne bloquent plus les actions. Utilisez getenforce pour confirmer le nouvel état.
Pourquoi getenforce est-il introuvable sur Debian ?
Les outils SELinux peuvent ne pas être installés, notamment sur une installation minimale. Debian utilise souvent AppArmor par défaut ; vérifiez les paquets installés et le mécanisme de sécurité actif avant de poursuivre.
Comment réactiver l’application des règles après un test ?
Si SELinux est toujours chargé, exécutez sudo setenforce 1, puis vérifiez que getenforce affiche Enforcing. Cette commande ne réactive pas SELinux s’il a été désactivé au démarrage avec selinux=0.
