Pavois
EN
Sections du handbook▾
Fondations
Comprendre les menaces qui pèsent sur un hôte LinuxPourquoi on durcitLes principes de défense derrière chaque règleConfiguration effective : la vérité qu'aucun fichier ne contientLes normes que Pavois cartographieModèle d'identifiant de contrôle SOCLEPreuves & exportsComment la note A-E est calculéeCe qu'un PASS prouve : le verdict qualifiéModèle de confiance du bundle de preuveSOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité)Ce que Pavois couvre, et ce qu'il ne couvre pas
Domaines
Durcir SSHDurcir PAMContrôle d'accès obligatoire (SELinux / AppArmor)Durcir le pare-feu localDurcir sudoPermissions et propriété des fichiersDurcir les montages et le système de fichiersDurcir les modules noyauDurcir le noyau et le réseau avec sysctlJournalisation d'audit avec auditdDurcir la journalisation avec journald et rsyslogDurcir les services systemdHygiène des paquetsDurcir le chargeur d'amorçage (GRUB)Synchroniser l'heureBannières de connexion et MOTDContrôler l'accès à cron et atDurcir le bureau GNOME (dconf)
Outillage
Annuler un durcissement : les points de restaurationExploiter Pavois : privilèges, air-gap, durée, dérogationsLancer Pavois en CI (GitHub Actions)État des fonctionnalités : livré, partiel, roadmapGouvernance : licence, versionnement, provenance, sécurité

Permissions et propriété des fichiers

Revu le

Des fichiers sensibles comme /etc/shadow, les clés SSH et les tâches cron ne valent que ce que valent leurs bits de permission. Resserrez les droits, posez un UMASK strict, éliminez les fichiers modifiables par tous et passez en revue les SUID/SGID pour qu'un compte peu privilégié ne puisse ni lire de secrets ni s'élever.

La menace : un bit de permission relâché transforme un pied dans la place en compromission

Le contrôle d'accès discrétionnaire est la dernière ligne de défense quand un attaquant a déjà un compte sur la machine. Une permission relâchée transforme un pied dans la place en compromission : un /etc/shadow lisible par tous livre tous les hachages de mots de passe pour un cassage hors-ligne ; un /etc/passwd, /etc/sudoers ou /etc/crontab modifiable par le groupe permet à un utilisateur non privilégié de réécrire les identités, la politique sudo ou une tâche cron root et de s'élever à volonté. Les fichiers modifiables par tous (-rw-rw-rw-) dans des chemins partagés comme /tmp sont un vecteur classique d'attaques par lien symbolique et par injection de configuration. Les binaires SUID/SGID s'exécutent avec les privilèges du propriétaire quel que soit l'appelant : un seul binaire setuid-root mal placé est un chemin direct vers root. Et des clés d'hôte ou clés privées SSH lisibles par other minent toute la chaîne de confiance.

Pourquoi le durcir

Les permissions sont faciles à rater et catastrophiques quand elles le sont. Aucun exploit à écrire : l'attaquant lit simplement le fichier ou exécute le binaire que le noyau l'autorise déjà à toucher. Durcir ce domaine garantit que, même après la compromission d'un compte, les secrets restent illisibles, les fichiers de politique restent intouchables et qu'il n'existe aucun chemin surprise vers root, réduisant le rayon d'impact de toute autre faille.

Principes de défense appliqués

  • Moindre privilège : les secrets reçoivent le mode minimal. /etc/shadow et /etc/gshadow illisibles par le groupe/les autres (0000 ou 0640), /etc/sudoers réservé à root (0440), /etc/passwd//etc/group en 0644, journaux d'audit en 0640 ou plus strict.
  • Réduction de la surface d'attaque : aucun fichier modifiable par tous non autorisé ; aucun bit SUID/SGID parasite là où il est inutile.
  • Intégrité plutôt que confidentialité quand il le faut : /etc/passwd doit rester lisible par tous pour fonctionner, la règle est donc qu'il soit non modifiable par le groupe/les autres ; les fichiers d'identifiants reçoivent les deux.
  • Traçabilité : les fichiers journaux sous /var/log sont verrouillés pour qu'un attaquant ne puisse ni lire ni altérer les traces.
  • Contrôle fin avec les ACL : quand les modes propriétaire/groupe/autres sont trop grossiers, les ACL POSIX (setfacl/getfacl) accordent à un utilisateur précis exactement l'accès nécessaire.

Poser un défaut strict avec UMASK 027

Chaque fichier créé par un processus hérite d'un mode masqué par le UMASK. Le défaut permissif 022 rend les nouveaux fichiers lisibles par tous ; 027 retire tout accès aux autres (et l'écriture au groupe), si bien qu'un journal, une clé ou une config fraîchement écrits sont privés par défaut. Posez-le dans /etc/login.defs (UMASK 027), renforcez-le via PAM (pam_umask), et dans /etc/profile//etc/bashrc. C'est un filet de sécurité à l'échelle du système : il corrige les fichiers que vous oubliez, pas seulement ceux que vous chmodez.

Traquer les fichiers dangereux

# Fichiers modifiables par tous (et repertoires sans sticky bit)
find / -xdev -type f -perm -0002 -ls
find / -xdev -type d -perm -0002 ! -perm -1000 -ls

# Inventaire SUID / SGID : a comparer a une baseline connue
find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -ls

# Fichiers sans proprietaire : l'UID d'un utilisateur supprime les possede encore
find / -xdev \( -nouser -o -nogroup \) -ls

Un fichier sans propriétaire est dangereux car un nouveau compte réutilisant cet UID en hérite silencieusement. Un binaire SUID surprise est le chemin d'escalade le plus court ; comparez l'inventaire à l'ensemble attendu de la distribution et faites chmod u-s sur tout ce qui est inattendu.

Ce que Pavois audite : le mode réel sur la cible

Les règles Permissions des fichiers de Pavois résolvent le mode et la propriété réels sur la cible (via la ressource file de CINC), pas ce qu'un modèle prétend. Il vérifie les fichiers d'identifiants/identité (/etc/shadow, /etc/gshadow ne portent aucun accès ; /etc/passwd, /etc/group sont non modifiables par le groupe/les autres, ainsi que leurs .bak), la politique de privilèges (/etc/sudoers, /etc/sudoers.d/), toute la surface cron/at, le matériel SSH (/etc/ssh, clés d'hôte, *.pub, sshd_config.d/), les fichiers du chargeur d'amorçage et les traces de journalisation. Chaque règle vérifie que les bits setuid/setgid/sticky sont absents là où ils doivent l'être, et une sentinelle modifiable par tous dédiée confirme que les chemins partagés comme /tmp ne sont pas modifiables par other. Ces contrôles sont mappés sur les sections permissions du CIS et ANSSI BP-028 R29/R50.

Pièges

  • Un chmod -R global casse des choses : resserrer /etc récursivement peut retirer les bits d'exécution des répertoires. Ciblez des fichiers précis.
  • Retirer un bit SUID légitime casse un outil (passwd, sudo, ping historiquement) : revoyez, ne retirez pas à l'aveugle.
  • Le UMASK à un seul endroit ne suffit pas : un shell de connexion, une tâche cron et un service systemd peuvent avoir chacun un umask différent ; posez-le dans login.defs et PAM.
  • /etc/passwd en 0600 casse la résolution des noms : il doit rester 0644 (lisible), seulement non modifiable par les autres.

FAQ

Pourquoi 0000/0640 sur /etc/shadow et pas 0644 ? Parce qu'il contient les hachages de mots de passe ; seul root (et le groupe shadow sur certaines distributions) en a besoin. Un shadow lisible par tous, c'est le cassage hors-ligne offert.

UMASK 022 ou 027 ? 027 pour un hôte durci : les nouveaux fichiers sont privés au propriétaire et au groupe, refusés aux autres. 022 les laisse lisibles par tous.

Comment trouver les chemins d'escalade oubliés ? Inventoriez les SUID/SGID (find -perm -4000), les fichiers modifiables par tous et les fichiers sans propriétaire ; comparez à la baseline de la distribution et à vos attentes.

Pour aller plus loinlogin.defs : UMASK et les valeurs par défaut des comptes ↗find : les chasses -perm, -nouser, -nogroup ↗guide des permissions et de la propriété des fichiers (blog.stephane-robert.info) ↗

Règles Pavois (66)

Vérifier les permissions du fichier /etc/at.allowVérifier les permissions du fichier /etc/at.denyVérifier que les outils d'audit ont le mode 0755 ou moinsLes permissions des fichiers de configuration d'audit sont 640 ou plus restrictivesVérifier les permissions du fichier de sauvegarde groupVérifier les permissions du fichier de sauvegarde gshadowVérifier les permissions du fichier de sauvegarde passwdVérifier les permissions du fichier de sauvegarde shadowTous les fichiers de configuration GRUB doivent avoir le mode 0600 ou plus restrictifVérifier les permissions du fichier /etc/cron.allowVérifier les permissions de cron.dVérifier les permissions de cron.dailyVérifier les permissions de cron.hourlyVérifier les permissions de cron.monthlyVérifier les permissions de cron.weeklyVérifier les permissions de cron.yearlyVérifier les permissions de crontabVérifier les permissions du grub.cfg du chargeur d'amorçage UEFIVérifier les permissions de /boot/grub2/user.cfgVérifier les permissions de /etc/audit/auditd.confVérifier les permissions de /etc/audit/audit.rulesVérifier les permissions de /etc/audit/rules.d/*.rulesVérifier les permissions du fichier /etc/crypttabVérifier les permissions du fichier groupVérifier les permissions du fichier gshadowVérifier les permissions du fichier /etc/ipsec.confVérifier les permissions du fichier /etc/ipsec.secretsVérifier les permissions du répertoire /etc/ipsec.dVérifier les permissions de la bannière de connexion systèmeVérifier les permissions de la bannière de connexion système pour les connexions distantesVérifier les permissions de la bannière du message du jour (MOTD)Vérifier les permissions du fichier passwdVérifier les permissions du fichier /etc/security/opasswdVérifier les permissions du fichier /etc/security/opasswd.oldVérifier les permissions du répertoire /etc/selinuxVérifier les permissions du fichier /etc/sestatus.confVérifier les permissions du fichier shadowVérifier les permissions du fichier /etc/shellsVérifier les permissions du fichier /etc/sudoersVérifier les permissions du répertoire /etc/sudoers.dVérifier les permissions du fichier /etc/sysconfig/sshdVérifier les permissions du répertoire /etc/sysctl.dVérifier les permissions de /boot/grub2/grub.cfgVérifier les permissions de la commande journalVérifier que les bibliothèques partagées ont des permissions restrictivesVérifier les permissions du fichier de configuration du serveur SSHVérifier les permissions du répertoire de configuration du serveur SSHVérifier les permissions du répertoire de drop-ins du serveur SSHVérifier les permissions des fichiers de clés publiques *.pub du serveur SSHS'assurer que le binaire sudo possède les permissions correctesVérifier les permissions sur les fichiers System.mapS'assurer qu'aucun fichier accessible en écriture par tous n'existeVérifier les permissions de /boot/grub2/user.cfgVérifier les permissions du répertoire /var/logVérifier les permissions des fichiers du répertoire /var/log/apt/.*Les journaux d'audit système doivent avoir le mode 0640 ou moins permissifVérifier les permissions du fichier /var/log/auth.logVérifier les permissions des fichiers /var/log/cloud-init.log(.*)Vérifier les permissions des fichiers dans /var/log/gdmVérifier les permissions des fichiers dans /var/log/gdm3Vérifier les permissions des fichiers /var/log/lastlog(.*)Vérifier les permissions des fichiers /var/log/localmessages(.*)Vérifier les permissions du fichier /var/log/messagesVérifier les permissions des fichiers dans /var/log/sssdVérifier les permissions du fichier /var/log/syslogVérifier les permissions des fichiers /var/log/waagent.log(.*)