Activer le service de politique d'accès aux fichiers (fapolicyd)
Garantit que le démon de liste blanche d'applications fapolicyd.service est activé et en cours d'exécution, afin que seuls les exécutables autorisés puissent s'exécuter.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pourquoi cette règle
Le service fapolicyd (File Access Policy Daemon) met en œuvre une liste blanche d'applications : il décide quels exécutables et bibliothèques peuvent s'exécuter selon une politique. Son exécution bloque le lancement de binaires non approuvés ou non autorisés, une défense solide contre les logiciels malveillants et les altérations de la chaîne d'approvisionnement.
Ce que vérifie Pavois
Pavois interroge l'état résolu de l'unité avec systemctl is-enabled / is-active pour fapolicyd.service. Lire l'état effectif confirme que le démon est réellement actif, et pas seulement installé ou activé dans un fichier d'unité qui pourrait être masqué ou échouer au démarrage.
describe service('fapolicyd.service') do
it { should be_enabled }
it { should be_running }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled fapolicyd.service (résultat attendu enabled) et systemctl is-active fapolicyd.service (résultat attendu active).
Inspecter et investiguer
Vérifiez systemctl show fapolicyd.service (champs UnitFileState, ActiveState) et journalctl -u fapolicyd.service ; les exécutions refusées sont consignées dans /var/log/fapolicyd-access.log et le journal d'audit /var/log/audit/audit.log.
Remédiation
Le plan harden de Pavois applique une ressource service sur fapolicyd avec les actions enable et start, de sorte que le démon de liste blanche démarre immédiatement et persiste après les redémarrages. Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | fapolicyd-cli --update 2>/dev/null; systemctl enable --now fapolicyd |
|---|---|
| name | enable-fapolicyd |
| not_if | systemctl is-active --quiet fapolicyd |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
fapolicyd applique une liste blanche : en mode contraignant, il peut bloquer des binaires légitimes non couverts par la politique (scripts personnalisés, logiciels installés hors dnf/rpm), cassant des applications voire la connexion. Précaution : avant d'activer, constituez/validez l'ensemble de règles, exécutez d'abord en mode permissif pour collecter les refus, et assurez-vous que la base de confiance (fapolicyd-cli --update) reflète vos logiciels installés, sinon vous risquez de vous priver d'outils nécessaires. Pas actif par defaut : sur une installation Alma/RHEL 8 standard, fapolicyd n'est ni installe ni demarre ; Pavois l'installe et l'active, d'ou le marquage danger:. Mode d'echec et retablissement : si la base de confiance est incomplete (le backend rpmdb ne s'est pas rempli, ou un demon a besoin d'un interpreteur/binaire hors du jeu RPM), fapolicyd refuse ces executions et le service concerne ne demarre pas ; le refus est consigne dans /var/log/fapolicyd-access.log (dec=deny), PAS dans les journaux du service. Retablissez en reconstruisant la base : systemctl stop fapolicyd; rm -f /var/lib/fapolicyd/*.mdb; fapolicyd-cli --update; systemctl start fapolicyd (une base saine contient des dizaines de milliers d'entrees, verifiez avec fapolicyd-cli --dump-db | wc -l). Faites confiance a un binaire supplementaire avec fapolicyd-cli --file add /chemin && fapolicyd-cli --update. Validez toujours en mode permissif (permissive = 1 dans /etc/fapolicyd/fapolicyd.conf) avant de passer en enforcing.