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.

# 1. Mode global enforcing (jamais disabled — RHCE refuse)
- ansible.posix.selinux:
    state: enforcing       # JAMAIS disabled, permissive seulement pour debug ponctuel
    policy: targeted
  become: true

# 2. Booléen SELinux (autoriser nginx à se connecter en réseau)
- ansible.posix.seboolean:
    name: httpd_can_network_connect
    state: true
    persistent: true       # survit au reboot — non négociable
  become: true

# 3. Contexte d'un répertoire applicatif (puis restorecon)
- community.general.sefcontext:
    target: '/srv/myapp(/.*)?'
    setype: httpd_sys_content_t
    state: present
  become: true

- ansible.builtin.command: restorecon -RFv /srv/myapp
  register: restorecon_out
  changed_when: restorecon_out.stdout != ""
  become: true

Sécurité non négociable :

state: enforcing point. JAMAIS disabled — c’est l’aveu d’incompétence qui désactive un mécanisme de sécurité validé par la NSA. permissive acceptable uniquement pour debug ponctuel, à remettre en enforcing immédiatement après. C’est aussi un objectif RHCE explicite — l’examen pénalise SELinux désactivé.
persistent: true sur seboolean: — sinon le booléen est appliqué en runtime mais perdu au reboot.
sefcontext: + restorecon — sefcontext modifie la base de contextes mais n’applique pas aux fichiers existants ; il faut toujours enchaîner avec restorecon -RFv pour relabéliser. Sinon vos fichiers ont l’ancien label et le service ne peut pas y accéder.
Diagnostiquer un déni : ausearch -m avc -ts recent côté managed node. Un Permission denied qui survit malgré chmod/owner correct = SELinux dans 90% des cas.

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"
- 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é.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/modules-rhel/selinux/ dans stephrobert/ansible-training.

Challenge — sur db1.lab :

Installer les prérequis Python SELinux.
SELinux en enforcing.
Activer httpd_can_network_connect persistant.
Définir httpd_sys_content_t sur /var/www/myapp/ + restorecon.

Validation pytest+testinfra :

ansible-playbook solution.yml
pytest -v labs/modules-rhel/selinux/challenge/tests/

4 tests vérifient enforcing, booléen on, et contexte appliqué.

Prochaines étapes

Module firewalld Compléter SELinux par les règles réseau pour défense-en-profondeur

Module sysctl Durcissement kernel : kptr_restrict, dmesg_restrict, randomize_va_space

Module file Définir owner/group/mode sur les fichiers servis par httpd (préalable à sefcontext)

Pivot Modules Vue d'ensemble des modules RHEL système