Comprendre et appliquer les permissions spéciales (SUID, SGID, bit collant)
Dans cette étape, vous allez explorer les permissions spéciales sous Linux : SUID (Set User ID), SGID (Set Group ID) et le Sticky Bit. Ces permissions offrent un contrôle accru sur l'exécution des fichiers et le comportement des répertoires.
Les permissions spéciales sont représentées par un chiffre supplémentaire dans le mode de permission octal, placé avant les trois chiffres standard (propriétaire, groupe, autres).
- SUID (Set User ID):
- Valeur octale: 4
- Effet sur les fichiers: Lorsqu'un fichier exécutable avec SUID est exécuté, il s'exécute avec les permissions du propriétaire du fichier, et non de l'utilisateur qui l'a exécuté. Ceci est couramment utilisé pour les programmes qui ont besoin de privilèges élevés pour effectuer certaines tâches, comme la commande
passwd (qui doit écrire dans /etc/shadow, un fichier appartenant à root).
- Dans la sortie de
ls -l: Un s apparaît à la place de la permission x (exécution) du propriétaire. Si le propriétaire n'a pas la permission d'exécution, un S majuscule apparaît.
- SGID (Set Group ID):
- Valeur octale: 2
- Effet sur les fichiers: Similaire à SUID, mais l'exécutable s'exécute avec les permissions du groupe propriétaire du fichier.
- Effet sur les répertoires: Les fichiers et sous-répertoires créés dans un répertoire activé SGID héritent de la propriété du groupe de ce répertoire, plutôt que du groupe principal de l'utilisateur qui les a créés. Ceci est très utile pour les répertoires partagés où tous les fichiers doivent appartenir à un groupe spécifique.
- Dans la sortie de
ls -l: Un s apparaît à la place de la permission x (exécution) du groupe. Si le groupe n'a pas la permission d'exécution, un S majuscule apparaît.
- Sticky Bit:
- Valeur octale: 1
- Effet sur les fichiers: Aucun effet.
- Effet sur les répertoires: Les utilisateurs peuvent créer des fichiers dans le répertoire, mais ils ne peuvent supprimer ou renommer que les fichiers dont ils sont propriétaires. Cela empêche les utilisateurs de supprimer ou de déplacer les fichiers d'autres utilisateurs dans un répertoire partagé (par exemple,
/tmp).
- Dans la sortie de
ls -l: Un t apparaît à la place de la permission x (exécution) des autres. Si les autres n'ont pas la permission d'exécution, un T majuscule apparaît.
Démontrons ces permissions spéciales.
Exemple SUID
Nous allons créer un simple programme C qui tente de lire un fichier restreint.
Tout d'abord, créez un fichier que seul root peut lire :
sudo touch ~/project/secret_data.txt
sudo chmod 600 ~/project/secret_data.txt
sudo chown root:root ~/project/secret_data.txt
Vérifiez ses permissions :
ls -l ~/project/secret_data.txt
Sortie :
-rw------- 1 root root 0 Jun 6 17:36 /home/labex/project/secret_data.txt
Maintenant, créez un programme C read_secret.c qui essaie de lire ce fichier :
nano ~/project/read_secret.c
Collez le code suivant dans read_secret.c :
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
FILE *fp;
char buffer[256];
printf("Attempting to read /home/labex/project/secret_data.txt...\n");
fp = fopen("/home/labex/project/secret_data.txt", "r");
if (fp == NULL) {
perror("Error opening file");
return 1;
}
while (fgets(buffer, sizeof(buffer), fp) != NULL) {
printf("%s", buffer);
}
fclose(fp);
printf("Successfully read file.\n");
return 0;
}
Enregistrez et quittez nano (Ctrl+S, Ctrl+X).
Compilez le programme :
gcc ~/project/read_secret.c -o ~/project/read_secret
Maintenant, essayez de l'exécuter en tant que labex :
~/project/read_secret
Vous devriez voir un message "Error opening file: Permission denied", car labex n'a pas accès en lecture à secret_data.txt.
Maintenant, faisons en sorte que read_secret appartienne à root et définissons le bit SUID.
sudo chown root:root ~/project/read_secret
sudo chmod u+s ~/project/read_secret
Vérifiez les permissions :
ls -l ~/project/read_secret
Sortie :
-rwsr-xr-x 1 root root 17704 Jun 6 01:02 /home/labex/project/read_secret
Remarquez le s dans l'ensemble des permissions du propriétaire. Maintenant, exécutez le programme à nouveau en tant que labex :
~/project/read_secret
Cette fois, il devrait lire le fichier avec succès (bien qu'il soit vide, donc aucun contenu ne sera imprimé, mais le message "Successfully read file." indique le succès). C'est parce que le bit SUID a fait en sorte que le programme s'exécute avec les permissions de root.
Exemple SGID (sur un répertoire)
Créons un répertoire partagé et un nouveau groupe.
sudo groupadd shared_group
sudo mkdir ~/project/shared_dir
sudo chown labex:shared_group ~/project/shared_dir
sudo chmod 770 ~/project/shared_dir
Maintenant, définissez le bit SGID sur shared_dir :
sudo chmod g+s ~/project/shared_dir
Vérifiez les permissions :
ls -ld ~/project/shared_dir
Sortie :
drwxrws--- 2 labex shared_group 6 Jun 6 01:02 /home/labex/project/shared_dir
Remarquez le s dans l'ensemble des permissions du groupe.
Maintenant, créez un fichier à l'intérieur de shared_dir :
touch ~/project/shared_dir/new_file.txt
Vérifiez la propriété de new_file.txt :
ls -l ~/project/shared_dir/new_file.txt
Sortie :
-rw-r--r-- 1 labex shared_group 0 Jun 6 01:02 /home/labex/project/shared_dir/new_file.txt
Même si le groupe principal de labex est labex, le fichier new_file.txt a hérité de la propriété du groupe shared_group de shared_dir en raison du bit SGID.
Exemple Sticky Bit
Le répertoire /tmp est un exemple classique de répertoire avec le sticky bit défini. Créons un répertoire similaire.
sudo mkdir ~/project/public_upload
sudo chmod 1777 ~/project/public_upload
Le 1 dans 1777 est la valeur octale du sticky bit. 777 accorde des permissions complètes au propriétaire, au groupe et aux autres.
Vérifiez les permissions :
ls -ld ~/project/public_upload
Sortie :
drwxrwxrwt 2 root root 6 Jun 6 01:02 /home/labex/project/public_upload
Remarquez le t dans l'ensemble des permissions des autres.
Maintenant, simulons un autre utilisateur créant un fichier dans ce répertoire. Puisque nous n'avons que l'utilisateur labex, nous allons créer un fichier en tant que labex puis essayer de le supprimer après avoir changé sa propriété en root (simulant un autre utilisateur).
Créez un fichier en tant que labex :
touch ~/project/public_upload/labex_file.txt
Changez sa propriété en root :
sudo chown root:root ~/project/public_upload/labex_file.txt
Maintenant, essayez de supprimer labex_file.txt en tant que labex :
rm ~/project/public_upload/labex_file.txt
Vous verrez une invite vous demandant si vous souhaitez supprimer le fichier protégé en écriture, et après avoir confirmé avec y, vous obtiendrez une erreur "Operation not permitted". C'est parce que le sticky bit empêche les utilisateurs de supprimer les fichiers dont ils ne sont pas propriétaires dans ce répertoire, même si labex a la permission d'écriture sur le répertoire public_upload. Seul root ou le propriétaire de labex_file.txt (root dans ce cas) peut le supprimer.
Pour nettoyer, vous aurez besoin de sudo pour supprimer labex_file.txt :
sudo rm ~/project/public_upload/labex_file.txt
Nettoyage
Supprimez les fichiers et répertoires créés, ainsi que l'utilisateur/groupe :
sudo rm -f ~/project/secret_data.txt ~/project/read_secret.c ~/project/read_secret
sudo rm -rf ~/project/shared_dir ~/project/public_upload
sudo groupdel shared_group
