← Toutes les règles
SOCLE-CLD-FSP-146// File permissionsmoyenneconfig persistante

Vérifier les permissions du répertoire /etc/selinux

Garantit que le répertoire /etc/selinux n'est pas modifiable par le groupe/les autres et ne porte aucun bit setuid/setgid/sticky, afin que seul root puisse modifier la configuration SELinux.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0
Un seul check, mappé sur 1 norme

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

/etc/selinux héberge la configuration SELinux, dont config qui décide si SELinux s'exécute en mode enforcing, permissive ou disabled au démarrage. Si le répertoire est modifiable par le groupe ou les autres, un utilisateur non privilégié pourrait y déposer ou remplacer des fichiers pour affaiblir ou désactiver le contrôle d'accès obligatoire, neutralisant la couche de confinement la plus forte du noyau. Les bits setuid/setgid sur un répertoire affectent les nouveaux fichiers, et un bit sticky non standard signale une altération. Seul root doit contrôler ce répertoire.

Ce que vérifie Pavois

Pavois lit les bits de mode réels du répertoire /etc/selinux sur la cible (écriture groupe/autres, setuid/setgid/sticky), les permissions effectives appliquées par le noyau, et non une base documentée. Les permissions de répertoire sont des métadonnées d'inode, aucun include ni drop-in ne peut donc les contourner. La garde only_if ignore le contrôle sur les systèmes sans SELinux.

only_if { file('/etc/selinux').exist? }
describe file('/etc/selinux') do
  it { should_not be_setuid }
  it { should_not be_writable.by('group') }
  it { should_not be_setgid }
  it { should_not be_writable.by('other') }
  it { should_not be_sticky }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%A %U %G' /etc/selinux. Attendu : mode drwxr-xr-x (0755) appartenant à root root, sans bit d'écriture pour le groupe/les autres ni bits s/t. Vérification rapide : find /etc/selinux -maxdepth 0 -perm /7022 ne doit rien renvoyer. Confirmez que SELinux est toujours actif avec getenforce (Enforcing).

Inspecter et investiguer

Les changements de permissions ne sont pas journalisés par défaut. Surveillez le répertoire avec auditd : auditctl -w /etc/selinux/ -p wa -k selinux, puis consultez avec grep 'key="selinux"' /var/log/audit/audit.log. Les refus de politique SELinux et les changements de mode apparaissent aussi via ausearch -m AVC / journalctl -t setroubleshoot. Mode et propriété actuels : stat /etc/selinux.

Remédiation

Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement : chown root:root /etc/selinux && chmod 0755 /etc/selinux. Cela supprime toute écriture groupe/autres et tout bit setuid/setgid/sticky tout en gardant le répertoire traversable par tous (nécessaire pour que les outils SELinux lisent config).

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

mode0755
path/etc/selinux
resourcefile
pavois harden plan local

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

Impact & précautions

Risque si mal réglé : un /etc/selinux modifiable permet à un utilisateur non-root de modifier config et de mettre SELinux en permissive ou disabled au prochain démarrage, supprimant silencieusement le contrôle d'accès obligatoire. Appliquer le correctif est sûr : 0755 root:root est le mode standard. Précaution : gardez le répertoire au moins en 0755 (traversable/lisible), le restreindre davantage peut casser load_policy, semanage et le chargement de la politique au démarrage.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R50direct2.0haute

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