Permissions et propriété des fichiers : durcir un système Linux

Des permissions trop ouvertes sont l'une des portes d'entrée les plus classiques d'une élévation de privilèges : un /etc/shadow lisible expose les empreintes de mots de passe, un fichier world-writable laisse modifier un script exécuté par root, un binaire setuid superflu devient un tremplin. Ce guide montre comment régler l'UMASK, corriger les permissions des fichiers système sensibles, et traquer les fichiers à risque (world-writable, setuid/setgid, sans propriétaire). Pour administrateurs Linux, sur Debian/Ubuntu et RHEL/AlmaLinux. Aligné CIS Benchmarks et ANSSI-BP-028. Toutes les sorties proviennent d'un test réel.

Ce que vous allez apprendre

Régler un UMASK restrictif (027) de façon persistante
Corriger les permissions des fichiers d'authentification (passwd, shadow, group)
Traquer les fichiers world-writable et poser le sticky bit
Inventorier les binaires setuid/setgid
Trouver les fichiers sans propriétaire

Prérequis

Un accès root (ou sudo). Les recherches find parcourent tout le système ; lancez-les en heures creuses sur un serveur très chargé.

Régler l'UMASK à 027

L'UMASK définit les permissions retirées aux nouveaux fichiers. Le défaut système est 022, qui laisse les fichiers lisibles par tout le monde. Le lab le confirme :

$ umask
0022
$ grep '^UMASK' /etc/login.defs
UMASK    022

La valeur recommandée est 027 (rien pour les « autres », lecture pour le groupe), ou 077 pour isoler complètement. On la fixe dans /etc/login.defs (utilisé par useradd et pam_umask) et dans les shells interactifs via un fichier dédié de profile.d :

sudo sed -i 's/^UMASK.*/UMASK\t\t027/' /etc/login.defs
echo 'umask 027' | sudo tee /etc/profile.d/99-umask.sh

Cette mesure correspond à la règle ANSSI-BP-028 R36 (« Modifier la valeur par défaut de UMASK ») et au contrôle CIS 5.4.3.3 (« Ensure default user umask is configured »).

Permissions des fichiers d'authentification

/etc/passwd et /etc/group doivent rester lisibles (de nombreux outils en dépendent) mais non modifiables par les non-root. /etc/shadow et /etc/gshadow, qui contiennent les empreintes de mots de passe, ne doivent jamais être lisibles par un utilisateur ordinaire.

La cible de shadow diffère selon la distribution, et c'est l'erreur la plus fréquente d'un guide « commun ». Le lab montre la différence réelle :

# Debian 12
-rw-r----- 1 root shadow /etc/shadow      # 640 root:shadow
# AlmaLinux 9
---------- 1 root root   /etc/shadow      # 000 root:root

Sur Debian/Ubuntu, le groupe shadow existe (le binaire passwd est sgid shadow), la cible est 640 root:shadow. Sur RHEL/AlmaLinux, c'est 0000 root:root : root accède au fichier malgré le mode 000, car le noyau ignore les permissions pour root.

Fichier	Debian/Ubuntu	RHEL/AlmaLinux
`/etc/passwd`, `/etc/group`	`644 root:root`	`644 root:root`
`/etc/shadow`, `/etc/gshadow`	`640 root:shadow`	`0000 root:root`
`/etc/ssh/sshd_config`	`600 root:root`	`600 root:root`

Debian/Ubuntu
RHEL/AlmaLinux

sudo chown root:root /etc/passwd /etc/group
sudo chmod 644 /etc/passwd /etc/group
sudo chown root:shadow /etc/shadow /etc/gshadow
sudo chmod 640 /etc/shadow /etc/gshadow

sudo chown root:root /etc/passwd /etc/group /etc/shadow /etc/gshadow
sudo chmod 644 /etc/passwd /etc/group
sudo chmod 0000 /etc/shadow /etc/gshadow

Ces contrôles correspondent à CIS 7.1.x (« System File Permissions », numérotés 6.1.x dans les benchmarks v1.0.0) et à la règle ANSSI R50 (« Restreindre les droits d'accès aux fichiers et aux répertoires »).

Traquer les fichiers world-writable

Un fichier modifiable par tous (o+w) peut être altéré par n'importe quel utilisateur ou processus compromis. Un répertoire world-writable sans sticky bit laisse supprimer les fichiers des autres. On les recherche avec find, en se limitant au système de fichiers courant (-xdev) :

# Fichiers modifiables par tous
sudo find / -xdev -type f -perm -0002

# Répertoires modifiables par tous SANS sticky bit
sudo find / -xdev -type d -perm -0002 ! -perm -1000

Avec find, -perm -0002 signifie « le bit d'écriture autres est positionné » (à ne pas confondre avec -perm /0002), et ! -perm -1000 exclut les répertoires qui ont déjà le sticky bit.

On corrige en retirant l'écriture « autres » sur les fichiers, et en posant le sticky bit sur les répertoires partagés qui doivent rester inscriptibles :

sudo find / -xdev -type f -perm -0002 -exec chmod o-w {} +
sudo find / -xdev -type d -perm -0002 ! -perm -1000 -exec chmod a+t {} +

Les répertoires /tmp et /var/tmp sont volontairement world-writable, mais protégés par le sticky bit (1777). Le lab le confirme : drwxrwxrwt. Cette mesure couvre CIS 7.1.11 et la règle ANSSI R54 (« Activer le sticky bit sur les répertoires inscriptibles »).

Inventorier les binaires setuid et setgid

Un binaire setuid root s'exécute avec les privilèges de root, quel que soit l'appelant. C'est nécessaire pour quelques outils (passwd, sudo, mount), mais tout binaire setuid superflu est un vecteur d'élévation de privilèges. On les inventorie :

sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \)

Le lab montre la liste légitime attendue (Debian) :

/usr/bin/chage   /usr/bin/chsh    /usr/bin/mount
/usr/bin/passwd  /usr/bin/newgrp  /usr/bin/umount
/usr/bin/chfn    /usr/bin/su      /usr/bin/gpasswd

passwd, sudo, su, mount, ping ont légitimement besoin du bit setuid. CIS (7.1.13) demande une revue documentée, pas une suppression systématique. La bonne méthode : établir une liste de référence et comparer à chaque audit.

sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \) | sort > /var/log/suid.baseline
# plus tard :
sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \) | sort | diff /var/log/suid.baseline -

Pour un binaire jugé inutile après revue, on retire le bit avec chmod u-s (setuid) ou chmod g-s (setgid). Cette démarche correspond aux règles ANSSI R56 et R57 (« Éviter l'usage d'exécutables setuid/setgid »).

Trouver les fichiers sans propriétaire

Un fichier dont l'UID ou le GID n'existe plus (compte supprimé) peut être « récupéré » par un futur utilisateur réutilisant le même identifiant numérique, qui hériterait alors de droits inattendus. On les traque :

sudo find / -xdev \( -nouser -o -nogroup \)

Sans parenthèses, find / -xdev -nouser -o -nogroup n'applique -xdev qu'à la première branche, à cause de la priorité de l'opérateur -o. Toujours grouper les alternatives avec \( ... \).

Après enquête, on réattribue chaque fichier à un propriétaire légitime ou on le supprime. Cette mesure couvre CIS 7.1.12 et la règle ANSSI R53 (« Éviter les fichiers ou répertoires sans utilisateur ou groupe »).

Vérifier

# UMASK
grep '^UMASK' /etc/login.defs            # UMASK 027
bash -lc umask                            # 0027

# Permissions des fichiers sensibles
stat -Lc '%n %a %U:%G' /etc/passwd /etc/shadow /etc/group /etc/gshadow /etc/ssh/sshd_config

# Les 3 recherches doivent renvoyer une sortie vide (hors setuid légitimes connus)
sudo find / -xdev -type f -perm -0002
sudo find / -xdev -type d -perm -0002 ! -perm -1000
sudo find / -xdev \( -nouser -o -nogroup \)

Sécurité et points de vigilance

UMASK 027 vs 077 : 027 est un bon compromis (collaboration par groupe) ; 077 isole chaque utilisateur, mais peut gêner des services qui partagent des fichiers par groupe.
shadow en 000 sur RHEL : ne pas le « corriger » en 640 par réflexe, c'est le comportement attendu et root y accède quand même.
setuid : inventorier et documenter, jamais supprimer en masse.

Dépannage

Symptôme	Cause probable	Solution
`passwd` échoue pour les utilisateurs	mauvais groupe/mode sur `/etc/shadow`	Debian : `640 root:shadow` ; RHEL : `0000 root:root`
UMASK toujours 022 dans un shell	`profile.d` non chargé ou login non rejoué	vérifier `/etc/profile.d/99-umask.sh`, rouvrir une session
`find` très lent	parcours réseau/montages	garder `-xdev`, cibler les systèmes locaux
Un service casse après `chmod o-w`	fichier légitimement partagé	restaurer le droit nécessaire, isoler par groupe

À retenir

UMASK 027 dans /etc/login.defs et /etc/profile.d/ (ANSSI R36, CIS 5.4.3.3).
/etc/shadow : 640 root:shadow sur Debian, 0000 root:root sur RHEL (ANSSI R50, CIS 7.1.x).
Traquer les world-writable (find -perm -0002) et poser le sticky bit sur /tmp (ANSSI R54, CIS 7.1.11).
Inventorier les binaires setuid/setgid et les comparer à une baseline (ANSSI R56/R57, CIS 7.1.13).
Trouver les fichiers sans propriétaire (find \( -nouser -o -nogroup \)) (ANSSI R53, CIS 7.1.12).
Toujours parenthéser le -o dans find, et préciser la version du benchmark CIS (7.1.x récent, 6.1.x en v1.0.0).

Prochaines étapes

Durcir les points de montage nodev, nosuid et noexec sur /tmp et /dev/shm.

Bannières d'avertissement issue, issue.net et la bannière SSH.

Le hub durcissement Linux La démarche complète et les autres mesures.