Dans la partie 1, on a vu les bases : rwx, l’octal, l’ordre de décision du noyau, et pourquoi chown vaut mieux que 777. Il restait deux questions : que fait ce s dans -rwsr-xr-x, et comment faire quand un propriétaire et un groupe ne suffisent plus ?

L’essentiel en 30 secondes

  • Un 4e chiffre, à gauche, porte trois bits spéciaux : setuid (4), setgid (2), sticky (1).
  • setuid : le programme tourne avec les droits de son propriétaire. Puissant, donc à surveiller.
  • setgid sur un dossier : les fichiers créés dedans héritent de son groupe. C’est la clé des dossiers partagés.
  • sticky sur un dossier : chacun ne peut supprimer que ses propres fichiers. C’est ce qui protège /tmp.
  • ACL : des droits pour d’autres utilisateurs ou groupes, avec un piège, le masque.

Le 4e chiffre

Bit Valeur Affiché Sur un programme Sur un dossier
setuid 4 s chez le propriétaire tourne avec l’UID du propriétaire ignoré sous Linux
setgid 2 s chez le groupe tourne avec le GID du groupe les nouveaux fichiers héritent du groupe
sticky 1 t chez les autres sans effet sous Linux suppression réservée au propriétaire du fichier

Un S ou un T majuscule veut dire que le bit est posé mais que le x en dessous manque. Sur un programme, c’est presque toujours une erreur.

setuid : le pouvoir de root, en dose contrôlée

/usr/bin/passwd appartient à root et porte le setuid (4755). Quand vous changez votre mot de passe, le programme tourne en root le temps d’écrire dans /etc/shadow, et ne fait rien d’autre.

Le danger commence quand le programme sait faire plus que ça. Le projet GTFOBins recense les binaires courants (find, vim, less, python…) qui ouvrent un shell root dès qu’ils sont setuid. Un chmod u+s /usr/bin/find « pour dépanner » donne root à tous les comptes locaux.

Deux réflexes simples :

# Faire l'inventaire, le garder, comparer de temps en temps
find / -xdev -type f -perm -4000 -exec ls -l {} + 2>/dev/null

# Ne pas honorer setuid sur les partitions de données (/etc/fstab)
/dev/mapper/vg-data  /srv  ext4  defaults,nosuid,nodev  0 2

Un nouveau binaire setuid apparu sans mise à jour de paquet, c’est un signal d’alerte.

Le setuid ne marche pas sur un script

« J’ai mis chmod u+s sur mon script bash, il ne tourne pas en root. » C’est normal et c’est voulu : Linux ignore le setuid sur les scripts #!. Entre la lecture de la ligne #! par le noyau et la réouverture du fichier par l’interpréteur, un attaquant pourrait remplacer le script.

Pour qu’un utilisateur lance une action précise en root, la bonne réponse est une règle sudo limitée à cette commande.

setgid : le dossier partagé propre

Le problème : Alice et Bob travaillent dans le même dossier, mais chacun crée ses fichiers dans son propre groupe, et l’autre ne peut pas les modifier. La solution :

groupadd projet
usermod -aG projet alice
usermod -aG projet bob
mkdir /srv/projet
chown root:projet /srv/projet
chmod 2770 /srv/projet

Le 2 en tête fait hériter le groupe projet à tout ce qui est créé dans le dossier. Pour qu’Alice et Bob puissent aussi modifier les fichiers l’un de l’autre, leur umask doit laisser l’écriture au groupe (002 ou 007).

Sticky bit : ce qui rend /tmp vivable

/tmp est en 1777 : tout le monde peut y écrire, mais le t empêche de supprimer les fichiers des autres. La bête existe donc bel et bien sur votre système, tenue en laisse par un t.

Ajouté au dossier partagé, il donne 3770 : chacun peut écrire, mais ne supprime que ses propres fichiers.

Pour vérifier qu’aucun dossier ouvert à tous n’a été oublié :

find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null

Les ACL : quand un seul groupe ne suffit pas

Le dossier compta doit être modifiable par le groupe compta et lisible par l’utilisateur auditeur. Avec un seul groupe par fichier, rwx ne sait pas faire. Les ACL, si :

setfacl -m u:auditeur:rX /srv/compta        # un utilisateur de plus
setfacl -d -m g:compta:rwX /srv/compta      # règle héritée par les nouveaux fichiers
getfacl /srv/compta                          # lire le résultat

Un + à la fin des droits (drwxrwx---+) signale une ACL. ls -l ne montre donc pas tout : pensez à getfacl.

Le piège du masque

Dès qu’on ajoute un utilisateur ou un groupe nommé, un masque apparaît. Il plafonne les droits de tout le monde sauf le propriétaire et les autres.

group::rwx          #effective:r-x
mask::r-x

Le groupe a rwx sur le papier, mais le masque le limite à r-x. Et sur un fichier qui a une ACL, chmod modifie le masque, pas le groupe. Un chmod 750 de routine peut donc retirer l’écriture à tous les utilisateurs nommés d’un coup. Sur ces fichiers, on passe par setfacl.

Pour aller plus loin

Deux mécanismes complètent le tableau, chacun mériterait son article :

  • Les capabilities découpent les pouvoirs de root. Pour écouter sur le port 80 sans être root : AmbientCapabilities=CAP_NET_BIND_SERVICE dans l’unité systemd, plutôt qu’un setuid.
  • SELinux et AppArmor ajoutent un contrôle par-dessus les droits Unix. Si un Permission denied résiste à des droits corrects, regardez leurs logs avant de toucher aux bits.

Les erreurs classiques

Erreur À faire à la place
chmod u+s sur un script règle sudo ciblée
setuid sur un binaire « pour dépanner » sudo ou capability précise
Dossier partagé 777 groupe dédié + 2770, ou 3770
chmod sur un dossier sous ACL setfacl
Ne regarder que ls -l getfacl quand il y a un +

Ce que je retiens

  • Les binaires setuid se comptent et se surveillent. Sur un script, le bit est ignoré, et tant mieux.
  • setgid sur un dossier pour partager, sticky bit pour que chacun garde ses fichiers.
  • Les ACL règlent ce que rwx ne sait pas faire, mais une fois en place, on oublie chmod.
  • Dans tous les cas, la question reste celle de la partie 1 : qui a besoin de quoi, et rien de plus.

Sources et références