← Toutes les règles
SOCLE-CLD-GEN-033// Hardening (misc)moyenneruntime effectif

Appliquer en mode enforce tous les profils AppArmor

Exige qu'AppArmor soit activé et aucun profil en mode complain, chaque profil chargé doit être en mode enforce.

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.

Un PASS prouve✓ actif maintenant? sur disque? survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.

Pourquoi cette règle

Un profil en mode complain ne fait que journaliser les violations de politique ; il ne les bloque pas et n'offre donc aucun confinement réel. Mettre chaque profil en mode enforce garantit que les contrôles d'accès obligatoires sont réellement appliqués : un service compromis est cantonné exactement aux fichiers, capacités et accès réseau autorisés, limitant les mouvements latéraux et l'élévation de privilèges.

Ce que vérifie Pavois

Pavois interroge aa-status pour l'état noyau en direct : il exige qu'AppArmor soit activé et que le nombre de profils complaining soit 0. Interroger aa-status reflète les profils réellement chargés dans le noyau et leur mode actuel, bien plus fiable que la lecture des fichiers de /etc/apparmor.d/, qui peuvent ne pas tous être chargés ou différer de la politique en vigueur.

describe command('[ "$(aa-status --complaining 2>/dev/null)" = "0" ] && [ -n "$(aa-status --enabled 2>/dev/null && echo y)" ] && echo ok || echo ko') do
  its('stdout.strip') { should eq 'ok' }
end

Comment vérifier qu’elle est appliquée

Exécutez aa-status. Attendez-vous à un nombre non nul de profiles are in enforce mode et à 0 pour profiles are in complain mode. aa-status --complaining doit afficher 0.

Inspecter et investiguer

Les décisions AppArmor sont journalisées via le sous-système d'audit du noyau dans /var/log/audit/audit.log (cherchez apparmor="DENIED" / apparmor="ALLOWED") ou dans /var/log/kern.log / journalctl -k. Le mode courant par profil est affiché par aa-status.

Remédiation

Le plan de durcissement de Pavois exécute une ressource exec qui appelle aa-enforce /etc/apparmor.d/* pour basculer chaque profil en mode enforce, protégée par un not_if qui l'ignore lorsque aa-status --complaining rapporte déjà 0 (idempotent). Appliquez-le avec pavois harden apply.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

commandaa-enforce /etc/apparmor.d/* 2>/dev/null; true
nameapparmor-enforce
not_iftest "$(aa-status --complaining 2>/dev/null)" = 0
resourceexec
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Passer en enforce des profils qui n'étaient qu'observés en mode complain peut soudainement bloquer des actions jusque-là tolérées, cassant les applications qui comptaient sur un accès non accordé par le profil. Avant d'appliquer, examinez /var/log/audit/audit.log pour les événements apparmor="ALLOWED"/complain afin de voir ce que chaque profil refuserait en enforce, corrigez les profils concernés (aa-logprof) et testez les services critiques. Un profil problématique peut être rétabli par service avec aa-complain <profil> sans désactiver AppArmor entièrement.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R45direct2.0haute
CIS1.3.1.4directper OS, see the benchmark tablehaute

Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.

Sources & références