Meilleures pratiques pour sécuriser les systèmes de fichiers Linux avec des permissions spéciales

Les permissions spéciales sont l'une de ces fonctionnalités Linux qui semblent mineures dans ls -l mais qui comptent beaucoup en production. Un s supplémentaire sur un binaire appartenant à root peut permettre aux utilisateurs ordinaires d'effectuer une tâche privilégiée restreinte. Un t manquant sur un répertoire de partage peut permettre aux utilisateurs de supprimer les fichiers des autres. Un bit SGID sur un répertoire de projet peut vous éviter un flux constant de problèmes de propriété de groupe.

L'objectif n'est pas de parsemer des bits spéciaux partout. L'objectif est de savoir quand SUID, SGID et le sticky bit résolvent un véritable problème d'accès, et quand ils créent un chemin de privilège que vous regretterez plus tard.

Rappel des permissions standard

Avant d'explorer les permissions spéciales, il est essentiel de se souvenir de la notation standard par triplet (rwx pour le propriétaire, le groupe et les autres). Ces permissions sont représentées numériquement à l'aide de valeurs octales (par exemple, 755 ou 644).

r (Lecture) = 4
w (Écriture) = 2
x (Exécution) = 1

Les permissions spéciales modifient ce comportement de base et sont représentées par un quatrième chiffre octal en tête (4, 2 ou 1).

Les permissions spéciales : SUID, SGID et le Sticky Bit

Les permissions spéciales ajoutent des fonctionnalités au-delà du contrôle d'accès standard. Elles sont généralement indiquées dans la sortie du listing long (ls -l) par un s ou un t remplaçant le drapeau x standard.

Permission	Valeur octale	Effet
SUID (Set User ID)	4	Le fichier s'exécute avec les permissions du propriétaire du fichier (pas de l'utilisateur qui l'exécute).
SGID (Set Group ID)	2	Le fichier s'exécute avec les permissions du groupe du fichier, ou les nouveaux fichiers héritent de l'ID de groupe du répertoire parent.
Sticky Bit	1	Empêche les utilisateurs de supprimer ou de renommer des fichiers appartenant à d'autres utilisateurs dans un répertoire partagé, même s'ils ont la permission d'écriture sur le répertoire.

1. Set User ID (SUID)

Le bit SUID est puissant et potentiellement dangereux s'il est mal utilisé. Lorsqu'il est défini sur un fichier exécutable, tout utilisateur exécutant ce fichier lance le processus avec les permissions du propriétaire.

Cas d'utilisation pratique : Utilitaires qui nécessitent des privilèges root pour effectuer une tâche spécifique, mais ne doivent pas accorder un accès root général à l'utilisateur.

Exemple : SUID sur `/usr/bin/passwd`

La commande /usr/bin/passwd nécessite généralement un accès root pour modifier le fichier sécurisé /etc/shadow. Elle a le bit SUID défini, permettant à un utilisateur standard d'obtenir temporairement les privilèges du propriétaire (root) uniquement pendant la durée de l'exécution de passwd pour changer son propre mot de passe.

Affichage de SUID : Remarquez le s dans l'emplacement d'exécution du propriétaire :

ls -l /usr/bin/passwd
# Exemple de sortie : -rwsr-xr-x 1 root root ... /usr/bin/passwd

Définition de SUID : Utilisez la valeur octale 4 combinée aux permissions standard (par exemple, 755 devient 4755) :

# En supposant que 'my_script' appartient à 'appuser'
chmod 4755 /path/to/my_script

Avertissement de sécurité pour SUID : Ne définissez jamais le bit SUID sur des shells à usage général (comme /bin/bash) ou des scripts de maintenance larges qui interprètent des entrées externes. Si un script a besoin de privilèges, une règle sudoers étroite, un petit helper révisé ou une API de service est généralement plus sûr.

Lorsque vous auditez un hôte, les fichiers SUID méritent une attention particulière car ce sont des croisements de privilèges intentionnels :

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdev maintient l'analyse sur le système de fichiers actuel, ce qui est utile lorsque /proc, les sauvegardes montées ou les systèmes de fichiers réseau rendraient le résultat bruyant. Sur les serveurs avec des montages séparés, analysez chaque système de fichiers réel intentionnellement.

2. Set Group ID (SGID)

Le bit SGID a deux fonctions principales selon qu'il est appliqué à un fichier ou à un répertoire.

A. SGID sur les fichiers exécutables

Lorsqu'il est défini sur un fichier exécutable, le processus s'exécute avec les permissions associées à la propriété du groupe du fichier, et non au groupe principal de l'utilisateur.

B. SGID sur les répertoires (Crucial pour les environnements partagés)

Lorsqu'il est défini sur un répertoire, tout nouveau fichier ou sous-répertoire créé à l'intérieur hérite automatiquement de la propriété du groupe du répertoire parent, plutôt que du groupe principal de l'utilisateur qui a créé le nouveau fichier.

Cas d'utilisation pratique : Dossiers de projet partagés où tous les contributeurs doivent avoir un accès de groupe unifié pour la collaboration.

Définition de SGID sur un répertoire : Utilisez la valeur octale 2 combinée aux permissions standard (par exemple, 775 devient 2775) :

# Définir la propriété du groupe sur 'developers' et activer SGID
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project

Cela gère l'héritage de groupe, mais ne garantit pas que chaque nouveau fichier soit accessible en écriture par le groupe. Le umask d'un utilisateur compte toujours. Si les contributeurs créent des fichiers avec un umask restrictif comme 077, les fichiers peuvent hériter du groupe developers mais rester illisibles ou non inscriptibles par le groupe. Pour les répertoires partagés, vérifiez le umask attendu, les ACL par défaut ou les paramètres de création de fichiers au niveau de l'application :

getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project

Les ACL par défaut sont souvent l'élément manquant dans les répertoires collaboratifs car elles appliquent les permissions aux nouveaux fichiers et répertoires créés sous le chemin.

3. Le Sticky Bit

Le Sticky Bit (ou attribut de texte de sauvegarde) est presque exclusivement utilisé sur les répertoires partagés pour contrôler la suppression de fichiers.

Lorsque le Sticky Bit est défini sur un répertoire, seul le propriétaire d'un fichier dans ce répertoire, ou l'utilisateur root, peut supprimer ou renommer ce fichier, même si le répertoire lui-même autorise l'accès en écriture pour les 'autres' (o+w).

Cas d'utilisation pratique : Répertoires partagés publics comme /tmp ou dossiers de téléchargement départementaux où les utilisateurs ne doivent pouvoir gérer que les fichiers qu'ils ont créés.

Exemple : Le répertoire `/tmp`

Le répertoire /tmp a souvent des permissions comme 1777. Le 1 indique que le Sticky Bit est actif.

ls -ld /tmp
# Exemple de sortie : drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

Le t à la fin confirme que le sticky bit est défini. Sans lui, tout utilisateur pourrait supprimer des fichiers créés par d'autres utilisateurs dans /tmp.

Définition du Sticky Bit : Utilisez la valeur octale 1 combinée aux permissions standard (par exemple, 777 devient 1777) :

chmod 1777 /var/public_uploads

Gestion complète : Combinaison de permissions spéciales

Les permissions spéciales sont souvent combinées. Le quatrième chiffre en tête est la somme des bits spéciaux souhaités (4+2+1 = 7).

Permissions souhaitées	Valeur octale
Standard `rwxr-xr-x` (755)	`755`
SUID + `rwxr-xr-x`	`4755`
SGID + `rwxr-xr-x`	`2755`
Sticky Bit + `rwxrwxrwx`	`1777`
SUID + SGID + Sticky Bit + `rwx` (Rarement nécessaire)	`7777`

Exemple de combinaison de SGID et Sticky Bit pour les dossiers partagés :

Pour créer un répertoire de collaboration partagé sécurisé où tous les utilisateurs font partie du groupe 'team', les nouveaux fichiers héritent du groupe 'team' et les utilisateurs ne peuvent pas supprimer les fichiers des autres :

Définir la propriété du groupe : chgrp team /data/projectX
Appliquer SGID (2) + Standard rwx (7) + Sticky Bit (1) $\rightarrow 2+1 = 3$ pour les bits spéciaux.
- En utilisant la somme explicite : SGID (2) + Sticky Bit (1) = 3. Permissions standard 775.
- Commande totale : chmod 3775 /data/projectX

En visualisant cela avec ls -ld, vous devriez voir à la fois s dans la position d'exécution du groupe et t dans la position d'exécution des autres :

drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX

Si le bit d'exécution est manquant, l'affichage utilise le S ou T majuscule. C'est généralement un signe d'avertissement sur les répertoires, car la permission d'exécution contrôle si les utilisateurs peuvent traverser le répertoire.

Erreurs courantes qui provoquent de véritables incidents

L'erreur la plus dangereuse est d'utiliser SUID pour éviter de concevoir une autorisation appropriée. Si un script de maintenance doit faire pivoter un fichier appartenant à une application, ne rendez pas tout le script effectivement root pour chaque utilisateur. Donnez à l'application une commande de service contrôlée, utilisez une règle sudoers étroite, ou changez la propriété pour que le compte de service puisse effectuer la tâche sans root.

Une autre erreur courante est de rendre les répertoires partagés accessibles en écriture au monde entier sans le sticky bit :

chmod 777 /srv/uploads

Cela semble pratique lors des tests. En production, tout utilisateur local qui peut accéder au répertoire peut être en mesure de renommer ou de supprimer les fichiers d'un autre utilisateur. Si le répertoire doit vraiment être accessible en écriture par de nombreux utilisateurs non liés, 1777 est généralement la base de référence plus sûre :

chmod 1777 /srv/uploads

Pour les répertoires appartenant à une équipe, 2775 plus un groupe réel est souvent mieux que l'écriture pour tous. Ajoutez le sticky bit uniquement si les membres de l'équipe ne doivent pas supprimer les fichiers des autres. Certaines équipes souhaitent des droits de nettoyage partagés ; d'autres non. Le modèle de permission doit correspondre à ce flux de travail.

Les sauvegardes et les déploiements peuvent également casser les permissions spéciales. Certains outils d'archivage et de copie préservent les modes par défaut ; d'autres non, sauf si vous passez les bons drapeaux. Après avoir restauré un système ou déployé un package binaire, vérifiez explicitement les bits spéciaux :

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project

Si /tmp revient en 0777 au lieu de 1777, ce n'est pas une différence cosmétique. Les utilisateurs peuvent interférer avec les fichiers des autres. Si un bit SUID requis est manquant sur un utilitaire système, les utilisateurs ordinaires peuvent soudainement perdre un comportement attendu. Si un bit SUID inattendu apparaît sur un fichier dans /home, /tmp ou un chemin de téléchargement d'application, traitez-le comme suspect jusqu'à preuve du contraire.

Auditer sans se noyer dans les résultats

Une analyse complète du système de fichiers peut être bruyante, en particulier sur les machines de build et les postes de travail des développeurs. Commencez par les zones les plus importantes :

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

La première commande examine les emplacements d'exécution normaux. La seconde vérifie les zones de travail temporaires accessibles en écriture où un exécutable privilégié serait beaucoup plus préoccupant. Sur un serveur propre, les fichiers SUID personnalisés dans des chemins accessibles en écriture au monde entier devraient être rares. Si vous en trouvez un, vérifiez la propriété, la source du package, l'heure de modification et s'il apparaît dans votre gestion de configuration.

Pour les répertoires, recherchez les chemins accessibles en écriture au monde entier sans le sticky bit :

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

Cela ne signifie pas que chaque résultat est une brèche. Cela signifie que chaque résultat mérite une raison. Certains répertoires d'application sont intentionnellement accessibles en écriture par un groupe de service, mais les répertoires publics accessibles en écriture sans protection sticky sont une source courante de problèmes.

Meilleures pratiques pour la sécurité des permissions spéciales

En raison des privilèges élevés accordés par SUID et SGID, ils doivent être gérés avec une extrême prudence.

Limiter la portée de SUID : Définissez SUID uniquement sur les exécutables binaires compilés qui sont nécessaires aux opérations standard (comme passwd, ping). N'appliquez jamais SUID aux scripts interprétés (Shell, Python, Perl) à moins qu'ils ne soient encapsulés dans un exécutable wrapper sécurisé qui valide les entrées.

Auditer régulièrement : Analysez périodiquement le système de fichiers pour détecter les fichiers SUID/SGID inhabituels à l'aide de la commande find :

# Trouver tous les fichiers avec SUID défini
find / -perm /4000 2>/dev/null
# Trouver tous les fichiers avec SGID défini
find / -perm /2000 2>/dev/null

Utiliser SGID pour la cohérence du groupe : Préférez SGID à la gestion manuelle de la propriété du groupe de fichiers dans les structures de données partagées ; il automatise l'héritage de groupe.
Sticky Bit pour les zones accessibles en écriture au public : Le Sticky Bit est essentiel pour tout répertoire destiné à un usage général par l'utilisateur où la suppression par des non-propriétaires doit être restreinte (par exemple, /tmp, /var/tmp).
Associer SGID avec les ACL lorsque la collaboration est importante : SGID gère la propriété du groupe ; les ACL par défaut gèrent les permissions que les nouveaux fichiers reçoivent.
Suivre les exceptions personnalisées : Si votre organisation approuve un binaire SUID ou SGID personnalisé, enregistrez le but, le propriétaire, le chemin attendu et la source de déploiement. Le privilège mystérieux est la partie qui fait mal plus tard.

Les permissions spéciales sont utiles car elles sont précises. Gardez-les ainsi. Utilisez SUID pour les transitions de privilèges étroites, SGID pour la propriété partagée et le sticky bit pour les répertoires partagés où les droits de suppression nécessitent des garde-fous.