Module SELinux Ansible : modes, booléens, contextes

SELinux est le système de contrôle d'accès obligatoire activé par défaut sur RHEL/AlmaLinux/Rocky en mode enforcing. Ansible expose 3 modules complémentaires pour le piloter :

ansible.posix.selinux:, état global (enforcing / permissive / disabled) + politique active.
ansible.posix.seboolean:, activer/désactiver les booléens SELinux.
community.general.sefcontext:, gérer les contextes de fichiers (avec restorecon pour appliquer).

Collections requises : ansible-galaxy collection install ansible.posix community.general. Prérequis paquets sur le managed node : python3-libselinux + policycoreutils-python-utils.

Ce que vous allez apprendre

Vérifier et modifier l'état SELinux global (modes).
Activer un booléen avec persistance (persistent: true).
Définir un contexte de fichier custom + restorecon -R.
Comprendre pourquoi state: disabled nécessite un reboot.
Diagnostiquer un service qui plante "à cause de SELinux".

Prérequis

Avoir ansible.posix et community.general installés.
Sur le managed node : python3-libselinux + policycoreutils-python-utils (les modules SELinux Ansible nécessitent ces bindings Python).

Les 3 modes SELinux

Mode	Effet
`enforcing`	Contraintes appliquées + violations bloquées (production RHEL)
`permissive`	Violations loguées mais pas bloquées (debug)
`disabled`	SELinux complètement désactivé (à éviter en prod)

- name: SELinux en enforcing (recommande prod)
  ansible.posix.selinux:
    policy: targeted
    state: enforcing

- name: Passer en permissive (debug temporaire)
  ansible.posix.selinux:
    policy: targeted
    state: permissive

Le module modifie /etc/selinux/config (effet après reboot) ET applique le mode maintenant (setenforce).

state: disabled nécessite un reboot pour prendre effet, le kernel doit recharger la politique. getenforce continue à afficher Enforcing jusqu'au reboot.

Booléens SELinux

Les booléens sont des switches qui activent/désactivent des règles spécifiques de la politique. Sur RHEL 10, on en compte ~300.

Booléen	Effet
`httpd_can_network_connect`	httpd peut faire des connexions sortantes
`httpd_can_network_connect_db`	httpd peut se connecter à une DB distante
`httpd_enable_homedirs`	httpd peut servir `~user/public_html/`
`nfs_export_all_rw`	NFS export en read-write
`samba_enable_home_dirs`	Samba peut partager les homes

- name: Autoriser httpd a se connecter au reseau (persistant)
  ansible.posix.seboolean:
    name: httpd_can_network_connect
    state: true
    persistent: true

persistent: true est critique en production : sans, le changement est perdu au reboot et le service replante avec les mêmes erreurs SELinux.

getsebool -a | grep httpd liste les booléens disponibles.

Contextes de fichiers (sefcontext)

Cas typique : déployer une app web dans un dossier custom (pas /var/www/html/). SELinux refuse à httpd de servir des fichiers qui n'ont pas le bon contexte.

- name: Definir le contexte httpd_sys_content_t pour /var/www/myapp
  community.general.sefcontext:
    target: '/var/www/myapp(/.*)?'
    setype: httpd_sys_content_t
    state: present

- name: Appliquer le contexte (restorecon)
  ansible.builtin.command: restorecon -Rv /var/www/myapp
  register: restorecon_result
  changed_when: "'relabeled' in restorecon_result.stdout"

Étapes :

sefcontext: ajoute la règle dans la politique (équivalent semanage fcontext -a).
restorecon -R applique la règle aux fichiers existants (sinon ils gardent leur ancien contexte).

Convention regex : (/.*)? à la fin pour matcher le dossier ET tous ses sous-éléments.

Diagnostiquer une violation SELinux

Si SELinux bloque, audit.log contient des entries type=AVC msg=audit ... denied :

ssh ansible@db1.lab 'sudo grep denied /var/log/audit/audit.log | tail -5'

L'outil audit2allow (paquet policycoreutils-python-utils) génère un module SELinux qui autorise exactement ce qui est bloqué :

sudo audit2allow -a -M myapp_local
sudo semodule -i myapp_local.pp

Mais : ne jamais audit2allow -a -M aveuglément en prod, c'est souvent une mauvaise idée. Préférer corriger le contexte (sefcontext) ou activer un booléen.

Le piège : SELinux désactivé

Pattern dangereux observé en prod :

# ❌ Mauvaise pratique : desactive SELinux "pour que ca marche"
- name: Régler le mode SELinux
  ansible.posix.selinux:
    state: disabled

Risques :

Surface d'attaque augmentée : SELinux est une couche de défense critique contre les exploits.
Audit échoué : RHCE EX294, CIS Benchmark, ANSSI exigent SELinux activé.
Drift dev/prod : le code marche en dev (SELinux off) mais plante en prod (SELinux on).

Bonne pratique : passer en permissive pour debug → identifier les contextes/booléens manquants → corriger → revenir en enforcing.

Pièges courants

Symptôme	Cause	Fix
`state: disabled` ignoré	Pas de reboot	Reboot nécessaire pour disabled
`seboolean` perdu au reboot	Oubli de `persistent: true`	Toujours `persistent: true` en prod
Fichiers sans le bon contexte après deploy	Oubli de `restorecon -R`	Lancer `restorecon -R` après `sefcontext:`
Module SELinux failed	Manque `python3-libselinux` ou `policycoreutils-python-utils`	Installer les prérequis Python

À retenir

ansible.posix.selinux: = état global (enforcing / permissive / disabled).
ansible.posix.seboolean: = booléens, toujours persistent: true en prod.
community.general.sefcontext: + restorecon -R = contextes de fichiers.
state: disabled nécessite un reboot.
policycoreutils-python-utils doit être installé sur le managed node.
Ne jamais désactiver SELinux sauf cas critique documenté.

Mettre en pratique

Les trois modules SELinux se complètent, et c'est en les enchaînant sur une même machine qu'on saisit qui fait quoi. Ce lab vous fait passer le système en enforcing, activer un booléen avec persistent: true pour qu'il tienne au redémarrage, puis déclarer un contexte via sefcontext avant de l'appliquer avec restorecon. La vérification lit l'étiquette réelle des fichiers, pas la tâche qui prétend l'avoir posée.

Module selinux : modes, booléens et contextes

$ dsoxlab run modules-rhel-selinux

Environnement : VM·Durée : ~55 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-rhel-selinux
dsoxlab check modules-rhel-selinux

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

Module reboot : le redémarrage qu'impose state: disabled, à piloter proprement depuis le playbook.
Module mount : un système de fichiers fraîchement monté arrive sans étiquette adaptée, c'est le cas type qui réclame un contexte explicite.
Modules assert et fail : refuser d'aller plus loin quand le mode SELinux constaté n'est pas celui attendu.