Groupes d’utilisateurs Linux et permissions des fichiers

Introduction

Linux est un système d’exploitation multiutilisateur. Chaque processus et chaque fichier appartient à un utilisateur, et chaque utilisateur possède un groupe principal ainsi que, éventuellement, des groupes supplémentaires. Ensemble, l’identité, la propriété et les bits de permission déterminent qui peut lire, modifier, exécuter ou parcourir une ressource.

Dans ce lab, vous allez créer un petit environnement d’équipe à l’aide de comptes réservés à l’entraînement. Vous allez créer un utilisateur, gérer l’appartenance aux groupes, sécuriser un fichier, examiner le verrouillage d’un compte, contrôler les permissions par défaut avec umask et configurer des répertoires avec sticky bit et setgid. Toutes les opérations restent dans l’environnement du lab et ne modifient pas le chemin de connexion par défaut de labex.

Examiner les identités et créer un utilisateur d’entraînement

Dans cette étape, vous allez examiner votre identité actuelle et créer un compte distinct pour les exercices sur les permissions. Linux représente un utilisateur par un nom d’utilisateur et un identifiant numérique (UID). Il enregistre également un identifiant de groupe principal (GID) ainsi que les éventuels groupes supplémentaires.

Commencez par vérifier l’identité du shell actuel :

whoami

La sortie doit être labex. Affichez maintenant l’UID, le groupe principal et les groupes supplémentaires associés à ce compte :

id

Les identifiants numériques exacts peuvent varier, mais la sortie les indique avec les libellés uid, gid et groups.

La création d’un compte modifie des fichiers système et nécessite donc des privilèges d’administration. sudo signifie « superuser do » : après avoir vérifié que le compte actuel est autorisé à le faire, il exécute la commande suivante avec des privilèges élevés. Utilisez-le uniquement pour la commande qui nécessite une administration et lisez entièrement la commande avant d’appuyer sur Entrée.

La commande useradd ci-dessous utilise trois options :

• -m crée le répertoire personnel.
• -U crée un groupe principal portant le même nom.
• -s /bin/bash sélectionne Bash comme shell de connexion du compte.

Créez un utilisateur d’entraînement nommé jack :

sudo useradd -m -U -s /bin/bash jack

Examinez le nouveau compte et son répertoire personnel :

id jack

ls -ld /home/jack

La sortie de id doit indiquer jack comme utilisateur et comme groupe principal. La liste du répertoire doit montrer que /home/jack existe et appartient à jack:jack.

Gérer les groupes supplémentaires

Dans cette étape, vous allez créer un groupe d’équipe et ajouter des utilisateurs à des groupes supplémentaires. Le groupe principal d’un utilisateur devient généralement le groupe propriétaire des nouveaux fichiers qu’il crée. Les groupes supplémentaires donnent accès à d’autres ressources partagées.

Créez un groupe nommé developers :

sudo groupadd developers

Les options usermod -aG signifient « ajouter aux groupes supplémentaires ». L’option -a est importante : sans elle, -G peut remplacer les appartenances supplémentaires existantes. Ajoutez jack aux groupes developers et sudo :

sudo usermod -aG developers,sudo jack

Ajoutez également labex au groupe developers. Le shell actuel n’acquerra pas immédiatement cette nouvelle identité de groupe ; vous l’actualiserez en toute sécurité lors de la dernière étape.

sudo usermod -aG developers labex

Examinez les deux comptes :

groups jack

groups labex

La première sortie doit inclure jack, developers et sudo. La seconde doit inclure developers. L’appartenance au groupe sudo permet à un compte authentifié de demander des privilèges élevés ; elle doit être accordée uniquement à des administrateurs de confiance.

Contrôler la propriété et les permissions d’un fichier

Dans cette étape, vous allez sécuriser un rapport d’équipe en lui attribuant un propriétaire, un groupe et un mode de permission précis. Une liste détaillée affiche d’abord le type du fichier, puis trois groupes de permissions correspondant au propriétaire, au groupe et aux autres utilisateurs.

Créez un rapport vide dans le répertoire du projet :

touch /home/labex/project/secure-report.txt

Modifiez simultanément le propriétaire et le groupe avec la forme user:group de chown :

sudo chown jack:developers /home/labex/project/secure-report.txt

Définissez le mode 640 :

sudo chmod 640 /home/labex/project/secure-report.txt

En notation numérique, la lecture vaut 4, l’écriture vaut 2 et l’exécution vaut 1. Ainsi :

• Le propriétaire 6 dispose des permissions de lecture et d’écriture (4 + 2).
• Le groupe 4 dispose uniquement de la permission de lecture.
• Les autres utilisateurs 0 n’ont aucun accès.

Examinez le résultat :

ls -l /home/labex/project/secure-report.txt

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/secure-report.txt

Les champs stables de stat doivent indiquer owner=jack group=developers mode=640.

Examiner et modifier le verrouillage d’un compte

Dans cette étape, vous allez vous entraîner à verrouiller temporairement un compte réservé à cet exercice, puis à le déverrouiller. Linux stocke les hachages des mots de passe et l’état des comptes dans /etc/shadow. Un ! placé au début du champ du mot de passe indique que l’authentification par mot de passe est verrouillée.

La configuration a créé un compte d’entraînement nommé contractor. Affichez uniquement le premier caractère de son champ de mot de passe afin que le hachage lui-même ne soit jamais affiché. Lisez le pipeline de gauche à droite : getent shadow contractor récupère l’enregistrement shadow du compte ; le premier cut utilise : comme séparateur et sélectionne le champ 2 ; le second cut conserve le caractère 1 de ce champ :

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Le caractère initial doit normalement être $, qui marque le début d’un format moderne de hachage de mot de passe. Verrouillez le compte avec usermod -L :

sudo usermod -L contractor

Examinez à nouveau le premier caractère :

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Il doit maintenant s’agir de !. Déverrouillez le compte avec usermod -U et vérifiez que le ! disparaît :

sudo usermod -U contractor

sudo getent shadow contractor | cut -d: -f2 | cut -c1

Dans ce scénario, le contractor a maintenant quitté l’équipe. Verrouillez définitivement le compte tout en conservant ses fichiers :

sudo usermod -L contractor

Le verrouillage de l’authentification par mot de passe ne supprime pas le compte, ne supprime pas son répertoire personnel et ne met pas nécessairement fin aux sessions existantes. Il ne faut pas le confondre avec la suppression d’un utilisateur ; cette méthode est utile lorsque les fichiers doivent être conservés pour être examinés.

Contrôler les permissions par défaut avec umask

Dans cette étape, vous allez utiliser umask pour contrôler les bits de permission retirés lors de la création de nouveaux fichiers et répertoires par le shell. Les programmes commencent généralement avec un mode maximal de 666 pour les fichiers ordinaires et de 777 pour les répertoires. Un masque 027 retire la permission d’écriture au groupe ainsi que toutes les permissions aux autres utilisateurs.

Créez un espace de travail pour l’expérience :

mkdir -p /home/labex/project/umask-demo

Enregistrez le masque actuel afin de pouvoir le restaurer plus tard. La syntaxe $(command) s’appelle une substitution de commande : le shell exécute la commande placée entre parenthèses et remplace toute l’expression par sa sortie. L’affectation stocke ce résultat dans original_umask ; comme pour les autres affectations du shell, aucun espace ne doit entourer =.

original_umask=$(umask)

Appliquez le masque 027, puis créez un fichier et un répertoire :

umask 027

touch /home/labex/project/umask-demo/private-note.txt

mkdir /home/labex/project/umask-demo/private-dir

Examinez les modes numériques obtenus :

stat -c '%a %n' /home/labex/project/umask-demo/private-note.txt /home/labex/project/umask-demo/private-dir

Le fichier doit avoir le mode 640, tandis que le répertoire doit avoir le mode 750. Les fichiers ne reçoivent pas automatiquement de bits d’exécution. Restaurez le masque initial du shell :

umask "$original_umask"

La modification de umask concerne les objets créés ensuite ; elle ne modifie pas les permissions des objets existants.

Protéger un répertoire partagé avec le sticky bit

Dans cette étape, vous allez configurer une boîte de dépôt publique dans laquelle chacun peut créer des fichiers, mais où les utilisateurs ne peuvent pas supprimer les fichiers appartenant à quelqu’un d’autre. Le mode ordinaire 777 accorde à tous les utilisateurs un accès complet au répertoire. L’ajout du sticky bit modifie les règles de suppression à l’intérieur du répertoire.

Créez le répertoire partagé et définissez le mode 1777. Le 1 initial active le sticky bit.

mkdir /tmp/shared-dropbox

chmod 1777 /tmp/shared-dropbox

Utilisez sudo -u pour créer un fichier avec chacun des comptes d’entraînement :

sudo -u jack touch /tmp/shared-dropbox/jack-note.txt

sudo -u contractor touch /tmp/shared-dropbox/contractor-note.txt

Demandez maintenant à jack d’essayer de supprimer le fichier du contractor :

sudo -u jack rm /tmp/shared-dropbox/contractor-note.txt

Cet échec est volontaire. Vous devez voir Operation not permitted, et le fichier du contractor doit rester présent. Examinez le répertoire :

ls -ld /tmp/shared-dropbox

Les permissions doivent se terminer par un t minuscule, par exemple drwxrwxrwt. Le t minuscule signifie que le sticky bit et la permission d’exécution pour les autres utilisateurs sont tous deux activés. Un T majuscule indiquerait que le sticky bit est activé sans la permission d’exécution correspondante.

Configurer un répertoire d’équipe avec setgid

Dans cette étape, vous allez préparer un répertoire de collaboration privé. Sur un répertoire, setgid fait hériter aux éléments nouvellement créés du groupe du répertoire plutôt que du groupe principal de leur créateur. Les fichiers de l’équipe restent ainsi associés à un groupe partagé.

Créez le répertoire :

mkdir /home/labex/project/team-share

Faites de jack le propriétaire et de developers le groupe propriétaire :

sudo chown jack:developers /home/labex/project/team-share

Définissez le mode 2770. Le 2 initial active setgid ; 770 accorde un accès complet au propriétaire et au groupe, tout en refusant l’accès aux autres utilisateurs.

sudo chmod 2770 /home/labex/project/team-share

Examinez le résultat :

ls -ld /home/labex/project/team-share

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/team-share

La liste détaillée doit afficher un s à la position de l’exécution du groupe, par exemple drwxrws---. Le s minuscule signifie que setgid et l’exécution pour le groupe sont tous deux actifs. Un S majuscule indiquerait que setgid est présent, mais que l’exécution pour le groupe est absente.

Setuid, représenté par un s à la position de l’exécution du propriétaire, est un autre bit spécial que l’on trouve couramment sur des exécutables système soigneusement contrôlés. Sachez le reconnaître lors de la lecture des permissions, mais ne l’ajoutez pas à des programmes arbitraires.

Actualiser l’appartenance aux groupes et vérifier l’héritage

Dans cette étape, vous allez activer l’appartenance au groupe developers dans un shell enfant et vérifier que setgid contrôle le groupe d’un nouveau fichier. Ajouter un utilisateur à /etc/group ne modifie pas les groupes supplémentaires d’un shell déjà en cours d’exécution.

Démarrez un shell enfant avec developers comme groupe actif :

newgrp developers

L’invite de commande peut être actualisée. Vous êtes toujours l’utilisateur labex, mais le shell enfant possède maintenant developers comme groupe effectif. Confirmez les deux identités :

id

Créez un fichier dans le répertoire setgid :

touch /home/labex/project/team-share/labex-note.txt

Examinez le nouveau fichier :

stat -c 'owner=%U group=%G mode=%a' /home/labex/project/team-share/labex-note.txt

Le propriétaire doit être labex, tandis que le groupe doit être developers. Setgid fait hériter le groupe propriétaire ; les bits de lecture et d’écriture du fichier dépendent toujours du processus qui le crée et de son umask.

Quittez le shell enfant et revenez à la session du terminal d’origine :

exit

Le fichier reste présent après la fermeture du shell enfant.

Résumé

Vous avez pratiqué le modèle fondamental d’identité et d’accès utilisé par les systèmes Linux. Vous avez créé un utilisateur et un groupe d’équipe, géré les appartenances supplémentaires, attribué la propriété et traduit les modes de permission numériques en règles d’accès concrètes. Vous avez également examiné le verrouillage d’un compte sans exposer son hachage de mot de passe.

Vous êtes ensuite allé au-delà des permissions ordinaires : umask a contrôlé les valeurs par défaut, le sticky bit a protégé les fichiers dans un répertoire public et setgid a conservé la propriété du groupe de l’équipe dans un répertoire de collaboration privé. Enfin, vous avez utilisé newgrp pour actualiser l’appartenance au groupe et vérifié le groupe hérité sur un fichier réel.