Introduction
Les outils de sécurité s'exécutent sous une identité utilisateur et les fichiers de preuve sont associés à des utilisateurs. Comprendre ces identités vous aide à choisir les permissions nécessaires à une tâche sans rendre chaque fichier accessible à tous les comptes.
Vous créerez un compte d'exercice dans Kali, lui attribuerez un répertoire de dossier privé et testerez les accès autorisés comme refusés. Ce lab porte sur les utilisateurs locaux et les permissions des fichiers ; les processus et les journaux seront abordés dans un autre lab.
Identifier les utilisateurs et créer un compte d'exercice
Dans cette étape, vous distinguerez l'identité d'un utilisateur ordinaire des pouvoirs d'administration et créerez un compte local distinct dans Kali.
Entrez dans le shell Kali préparé, puis sélectionnez l'espace de travail partagé :
kali
cd /home/labex/project
id affiche votre identifiant numérique d'utilisateur (UID), votre identifiant de groupe principal (GID) et les groupes auxquels vous appartenez :
id
Le nom d'utilisateur est kali ; les identifiants numériques peuvent varier selon l'environnement. L'UID 0 identifie root, l'administrateur. Votre compte ordinaire possède un UID non nul.
sudo exécute une commande autorisée avec des privilèges plus élevés. Ce conteneur d'entraînement permet à l'apprenant Kali de l'utiliser sans mot de passe. Cette permission est locale au conteneur ; elle ne justifie pas d'exécuter toutes les commandes en tant que root. Demandez à root de s'identifier pour une seule commande :
sudo whoami
La sortie est root. L'élévation prend fin avec cette commande :
whoami
La sortie est toujours kali.
Un compte local possède un nom, un UID, un groupe, un répertoire personnel et un shell de connexion. useradd crée un compte et exige des droits d'administration. --create-home crée son répertoire personnel, --user-group crée un groupe principal du même nom et --shell /bin/bash choisit Bash comme shell :
sudo useradd --create-home --user-group --shell /bin/bash practice-analyst
Faites-le une seule fois dans un lab neuf ; un message signalant un compte existant signifie que le compte est déjà présent. Cet exercice ne nécessite ni mot de passe ni accès SSH. Examinez la nouvelle identité en passant son nom à id :
id practice-analyst
La sortie nomme practice-analyst comme utilisateur et comme groupe principal. Son UID doit être différent de ceux de kali et de root.
Attribuer la propriété et des permissions privées
Dans cette étape, vous créerez un répertoire de dossier, transférerez sa propriété et limiterez l'accès au compte qui lui est attribué.
Revenez à l'espace de travail partagé :
cd /home/labex/project
Créez un répertoire avec votre compte utilisateur ordinaire :
mkdir case-files
ls -ld décrit le répertoire lui-même : -l demande une sortie détaillée, tandis que -d empêche d'en lister le contenu à la place :
ls -ld case-files
La sortie comprend les caractères de permission, un propriétaire et un groupe. Le propriétaire initial est kali. Le premier caractère d signifie répertoire. Les neuf positions suivantes forment trois groupes de bits de lecture (r), écriture (w) et exécution (x) pour le propriétaire, le groupe et les autres. Sur un répertoire, la lecture liste les noms, l'écriture modifie les entrées et l'exécution permet de traverser le répertoire pour accéder aux entrées.
chown change la propriété. La forme user:group attribue à la fois le propriétaire et le groupe ; des droits d'administration sont nécessaires pour transférer la propriété à un autre compte :
sudo chown practice-analyst:practice-analyst case-files
chmod modifie les permissions. Sous forme numérique, la lecture vaut 4, l'écriture 2 et l'exécution 1. La somme 7 donne les trois ; 0 n'en donne aucune. Le mode 700 donne tous les accès au propriétaire et aucun accès au répertoire pour le groupe ou les autres :
sudo chmod 700 case-files
ls -ld case-files
Le début doit indiquer drwx------ et le propriétaire comme le groupe doivent être practice-analyst. Les dates et tailles numériques peuvent varier. La propriété choisit quel compte reçoit les permissions du propriétaire ; le mode définit ensuite l'accès accordé à chaque catégorie.
Tester l'accès avec le compte prévu
Dans cette étape, vous vérifierez l'accès avec de véritables identités utilisateur plutôt que de vous fier uniquement à l'affichage des permissions.
sudo -u NAME exécute une commande avec l'utilisateur nommé plutôt qu'avec root. Utilisez le propriétaire du dossier pour créer un fichier dans son répertoire privé :
sudo -u practice-analyst touch /home/labex/project/case-files/checked.txt
Aucune sortie n'est attendue. Examinez le résultat avec le même compte :
sudo -u practice-analyst ls -l /home/labex/project/case-files
Le fichier vide checked.txt doit appartenir à practice-analyst. Sa création prouve que ce compte peut traverser le répertoire et y écrire.
Le compte Kali ordinaire ne doit pas avoir cet accès. L'échec de la prochaine commande est attendu, avec un message de permission refusée qui démontre la restriction. Continuez après l'erreur :
ls /home/labex/project/case-files
Root peut toujours examiner le répertoire grâce à une commande explicitement autorisée :
sudo ls /home/labex/project/case-files
Vous devriez voir checked.txt. Les permissions privées restreignent les comptes ordinaires ; root conserve les pouvoirs d'administration. Continuez à utiliser kali pour le travail normal et élevez uniquement l'opération particulière qui l'exige. Aucune de ces commandes ne modifie le compte apprenant de l'hôte ni la façon dont LabEx se connecte à la VM.
Résumé
Vous avez examiné les identités utilisateur, utilisé sudo pour des actions d'administration précises, créé un compte et attribué la propriété et les permissions d'un répertoire. Vous avez confirmé que le compte prévu pouvait travailler tandis qu'un autre compte ordinaire se voyait refuser l'accès.
