L’arborescence Linux

Comme on l’a vu dans les guides précédents, les répertoires et fichiers Linux sont organisés en arborescence, en partant de la racine, jusqu’aux branches.

Première exploration

La racine de cette arborescence est notée / et représente l’origine de tous les répertoires inférieurs.
Note qu’il est possible d’afficher ce qui est contenu dans cette racine, en utilisant simplement la commande ls.

ls

On remarque que beaucoup de répertoires déjà connus sont présents, notamment /boot/ qui contient les fichiers système nécessaires au démarrage du système, ou bien /home/ qui contient les fichiers des utilisateurs.

Ici on peut noter le répertoire /root/, qui contient les fichiers du compte super-utilisateur et qui est donc séparé des autres répertoires « home ».

Le répertoire /dev/ contient les descripteurs de fichiers du matériel connecté au système… qu’il soit considéré comme du matériel physique tel qu’un disque (/dev/disk ou /dev/sda1) ou du matériel virtuel (aussi appelé pseudo-périphérique), tel que les terminaux (tty).

Souviens-toi que si sous Linux, tout est représenté par un fichier, ce n’est pas toujours exact de les considérer comme tel.

Dans l’exemple de /dev/, les fichiers qui représentent le matériel sont en réalité utilisés comme interface entre le système et la cible.

C’est un moyen rapide et mémorisable par des humains d’envoyer/recevoir des données depuis un équipement.

On voit aussi le répertoire /mnt/ que nous avons utilisé plus tôt comme racine des points de montage pour le stockage amovible.

Source : https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Source : https://tldp.org/LDP/sag/html/dev-fs.html

Bonus

• Où se trouvent les binaires et utilitaires système ?
• Quelle est la différence entre /mnt et /media ?
• Quelles pourraient être les raisons de séparer les répertoires Home des utilisateurs et du compte root ?
• Est-ce que cette organisation générale est obligatoire ou simplement suggérée ? Quel intérêt ?

Root et Sudo

Le compte Root

Le compte root d’un système est considéré comme le super-utilisateur ultime, ayant tous les droits sur le système et ses composants.

Détenir autant de pouvoir est, certes, très confortable et grisant, mais aussi très risqué.
Il existe mille et une façon de détruire son système en une seule commande, et une simple erreur de frappe peut potentiellement avoir des effets dramatiques.

Le risque est également présent côté sécurité… que se passe-t’il si un acteur malintentionné arrive à compromettre ton compte root ?
Oui t’as deviné, c’est la fin des haricots.

C’est pour cette raison que beaucoup (nous y compris) te recommanderont de ne pas utiliser ton Linux de tous les jours via son compte root, mais plutôt avec un compte utilisateur standard, en accédant aux permissions super-utilisateur uniquement lorsque c’est nécessaire.

Grâce à la commande su, il est possible de changer d’utilisateur en saisissant son mot de passe… et d’ailleurs, le compte root sera ciblé par défaut si tu ne spécifies pas l’utilisateur.

Pour revenir à ton utilisateur initial, tu peux soit simplement quitter la session shell ouverte avec exit, soit à nouveau changer d’utilisateur avec su.

su - root
# ou
su -

exit
# ou
su user

Sudo

Le gros inconvénient de cette méthode, en plus de multiplier les étapes, c’est que chaque utilisateur voulant accéder aux permissions super-utilisateur devra forcément connaitre le mot de passe du compte root… et c’est un risque de sécurité supplémentaire.

Note également que cette méthode te donnes des droits élevés sur l’ensemble du système, et pas juste pour une commande précise… ça manque clairement de granularité.

Heureusement, une autre solution existe sous la forme de la commande sudo.
Cette commande permet de donner temporairement à un utilisateur les privilèges d’un autre utilisateur (ici, root), et de déterminer quelles sont les commandes ou fonctionnalités auxquelles il aura accès.

Une fois configuré, il suffit à l’utilisateur de saisir sa commande précédée de sudo pour l’exécuter avec les privilèges spécifiés.
Le mot de passe de l’utilisateur en cours sera demandé, mais pas celui du compte privilégié, et si la commande est autorisée par sudo, elle sera exécutée.

Si tu obtiens une erreur lors de l’utilisation de sudo, c’est normal pas de panique… on va régler ça très rapidement.

sudo cat /etc/shadow

Pour consulter les privilèges configurés pour l’utilisateur actuel, on peut utiliser la commande sudo avec l’option -l, ou simplement lire le fichier /etc/sudoers.

sudo -l

cat /etc/sudoers

Le fichier de configuration est organisé par ligne, chacune appartenant à un utilisateur recevant les privilèges et noté dans la première colonne.

La seconde colonne indique quel hôte est concerné, puis entre parenthèse l’utilisateur et le groupe dont on pourra utiliser les privilèges.

La dernière colonne indique, elle, les commandes qui sont autorisées lors de l’utilisation de sudo.
Tu pourras remarquer que le mot clé ALL peut être utilisé en deuxième et troisième colonne pour englober toutes les options possibles.

Note que d’autres mots clés sont disponibles, incluant le très dangereux NOPASSWD, permettant d’utiliser sudo sans entrer de mot de passe… les apprentis hackers vont t’adorer si tu l’utilises =)) !

Par défaut, tous les membres du groupe sudo sont autorisés à utiliser n’importe quelle commande en tant que root.

Pour donner accès à des droits super-utilisateur très rapidement, il te suffira donc d’y ajouter l’utilisateur ciblé (en commençant par le notre) avec la commande usermod.

su -
usermod -a -G sudo user

Normalement, les droits sont déjà appliqués, mais dans certains cas, un redémarrage du système sera nécessaire.
Dans tous les cas, c’est une bonne excuse pour apprendre une nouvelle commande…

Redémarre la machine pour appliquer les droits et connecte toi avec ton utilisateur.

systemctl reboot

Teste tes nouveaux pouvoirs en créant un nouvel utilisateur et en l’ajoutant au groupe sudo sans passer par le compte root.

sudo adduser max
sudo usermod -a -G sudo max

Connecte-toi avec le nouvel utilisateur (ou change avec su) et essaye d’afficher le fichier /etc/shadow.

sudo cat /etc/shadow

Bonus

• Quels sont les dangers d’éditer le fichier sudoers avec un éditeur classique ? Quelle alternative est conseillée ?
• A quoi correspondent les lignes rangées dans la section Matching Default entries lors de l’exécution de la commande sudo -l ?
• Quelle est l’utilité de env_reset ? Quel danger si cette option n’est pas présente ?

Lire les permissions

La notation

Chaque répertoire et fichier sur un système Linux possède un propriétaire et des permissions.
Ces deux caractéristiques permettent de déterminer ce qu’il est possible de faire ou non avec l’objet concerné.

La commande ls avec l’option -l permet d’afficher tous les détails nécessaires.

ls -l

Pour commencer, nous allons nous intéresser à l’utilisateur propriétaire, et il s’agit du nom présent dans la 3ème colonne.

Lorsqu’un utilisateur créé un répertoire ou un fichier, il devient automatiquement propriétaire de celui-ci, mais nous verrons juste après qu’il est possible de le changer.

Dans la 4ème colonne, on peut également observer le nom du groupe propriétaire, qui n’est pas nécessairement un groupe auquel le propriétaire est assigné… mais encore une fois, c’est le groupe primaire du propriétaire qui est assigné par défaut lors de la création d’un répertoire ou d’un fichier.

Pour l’instant, on est d’accord, ça ne nous avance à rien et aucune information sur qui peut faire quoi… mais on y vient.

Si nous revenons dans la première colonne, on note une syntaxe bizarre, composée de r, w, x, -, . et autres caractères.

Cette séquence est en fait une façon simplifiée d’afficher et d’attribuer des permissions ou caractéristiques à un objet.

Le premier caractère est un cas spécial et indique s’il s’agit d’un répertoire (d), d’un lien symbolique (l) ou d’un fichier (-).

Les 9 prochains caractères fonctionnent par groupe de 3 et peuvent indiquer un droit de lecture (r), un droit d’écriture (w) ou un droit d’exécution (x).

Note que si un des droits n’est pas accordé, il est remplacé par un tiret (-) pour conserver la structure générale de la notation.

Donc, dans l’ordre, nous avons 3 caractères représentent les permissions accordées à l’utilisateur propriétaire, puis 3 caractères qui représentent les permissions du groupe propriétaire et pour finir, les 3 caractères qui représentent celles de tous les autres utilisateurs.

Exemple

Prenons un exemple concret.

Dans l’image ci-dessus, on observe que le répertoire /root/ appartient à l’utilisateur et au groupe root, comme affiché dans les 3èmes et 4èmes colonnes.

Les droits affichés en première colonne sont drwx———, ce qui signifie que cet objet est un répertoire (d), que l’utilisateur root a les droits d’écriture, lecture et exécution (rwx), que les membres du groupe root n’ont aucun droit (—), et que tous les autres utilisateurs non plus (—).

Un second exemple serait le répertoire /srv/, dont le propriétaire est également l’utilisateur et groupe root.

Les droits indiquent que c’est une répertoire (d), que l’utilisateur root a les droits d’écriture, lecture et exécution (rwx), que les membres du groupe root ont les droits de lecture et d’exécution mais pas d’écriture (r – x), et que tous les autres utilisateurs ont des droits similaires (r – x).

Bonus

• Recherche 5 fichiers/répertoires sur ton système ayant des permissions différentes et décris les permissions accordées en une seule phrase à chaque fois.
• Est-ce possible d’attribuer des droits d’exécution sans droits de lecture ?

Configurer le Propriétaire et les Permissions

Chown

Pour changer le propriétaire d’un objet, la commande chown doit être utilisée.
Note que changer les permissions ou le propriétaire d’un objet peut nécessiter des privilèges élevés, ce qui impliquera d’utiliser la commande en tant que root, ou via sudo.

sudo chown root:root test.txt

Dans le cas ou tu voudrais changer le propriétaire d’un répertoire ainsi que de tous ses sous-répertoires et fichiers, il faudra utiliser l’option -R pour activer la récursivité.

sudo chown -R root:root testdir/

Chmod

Changer les permissions est possible grâce à la commande chmod, mais avant de l’utiliser, nous allons devoir discuter d’une notation un peu spéciale qui sera utilisée ici.

Pour le système Linux, les permissions sont encodées sous forme binaire… et il est bien plus simple pour lui de les représenter sous forme octale (c’est à dire sur une base 8).

Concrètement, ça veut dire que chaque trio de permissions (rwx) peut être représenté par un nombre unique si on donne a ces permissions une valeur fixe.

Dans ce cas, la permission de lecture (R) à une valeur de 4, la permission d’écriture (W) à une valeur de 2, et la permission d’exécution (X) a une valeur de 1.

Ces valeurs fixes et uniques peuvent être additionnées pour indiquer rapidement (et surtout efficacement pour Linux) les permissions accordées.

Par exemple, un total de 5 indique des permissions de lecture et d’exécution (4+1=5), alors qu’un total de 7 indique toutes les permissions (4+2+1=7).

Si on applique cette logique à un exemple précédent, il devient très simple de noter l’ensemble des permissions.

Par exemple, avoir des permissions 644 sur un fichier appartenant à l’utilisateur john et au groupe ITGroup, indique que john à les permissions de lecture et d’écriture, et que le groupe ITGroup ainsi que tous les autres utilisateurs ont la permission de lecture uniquement.

Cette notation dite octale est utilisée par de nombreux outils, dont chmod qui nous permet de paramétrer les permissions.

sudo chmod 644 testdir/

Bonus

• Recherche à nouveau 5 fichiers/répertoires sur ton système ayant des permissions différentes et convertis les permissions en valeur octale, puis décris les permissions accordées en une seule phrase à chaque fois.

Les permissions Set User et Set Group

SUID/GUID

Certains programmes ne peuvent correctement fonctionner qu’en ayant des privilèges élevés, notamment ceux du compte root… mais donner ce genre de privilèges à tous les utilisateurs ayant besoin de l’exécuter serait une faute majeure en terme de sécurité.

Les permissions Set User ID (SUID) et Set Group ID (SGID) sont utilisées dans ces cas spéciaux et permettent de forcer un fichier exécutable à être exécuté avec les permissions de son utilisateur ou groupe propriétaire.

La pratique la plus courante est donc de configurer le compte root (ou son groupe) en tant que propriétaire et d’activer la permission spéciale SUID (ou SGID), et bien entendu de donner les droits d’exécution aux utilisateurs concernés.

Lorsqu’un utilisateur exécutera le binaire, les permissions accordées seront temporairement celle du compte (ou groupe) propriétaire et seront retirées à la fin de l’exécution.

Cette permission spéciale est indiquée par le caractère s (pour « set ») dans les permissions du fichier, positionnée à la place du x (pour « execute ») du propriétaire pour le SUID et à la place du x du groupe pour le SGID.

Il est possible d’utiliser la commande chmod ici aussi pour activer ces permissions spéciales, en ajoutant un octet de permissions avant les permissions classiques.
Une valeur de 4 indique une permission SUID et une valeur de 2 indique une permission SGID.

Exemple

Pour illustrer, essayons de créer un script bash qui ira lire le contenu d’un fichier uniquement accessible par le compte root…

nano test.sh

#!/bin/bash
cat /etc/shadow

sudo chown root:root test.sh
sudo chmod 4755 test.sh

Parfait, la couleur rouge indique que le fichier est exécutable avec des droits SUID/SGID, essayons tout de suite.

./test.sh

Comme tu peux le voir, quelque chose ne va pas.

Le script n’est pas lancé avec les permissions du compte root et on obtient une erreur…
… mais c’est tout à fait normal et même rassurant.

Les scripts bash avec de telles permissions sont extrêmement dangereux lorsque mal utilisé ou mal conçus, et peuvent permettre à un utilisateur lambda d’obtenir les droits root de façon permanente.

Ce genre de technique est appelé une élévation de privilège ou un pivot vertical en cybersécurité, et les systèmes Linux modernes tentent de vous protéger contre les abus les plus évidents.

Source : https://en.wikipedia.org/wiki/Setuid

Si tu souhaites utiliser les capacités SUID/SGID, il faudra te tourner vers d’autres genre de fichiers exécutables, comme des binaires ou des scripts écrits dans un autre langage.

ls -l /usr/bin/su*

Bonus

• Cherche quelques binaires ou scripts possédant des droits SUID/SGID sur ton système.
• Explore le site https://gtfobins.github.io/ et essaye de comprendre le but de ce projet.

UID et GID

La notation

Depuis le début de ce chapitre, nous utilisons des noms pour désigner les utilisateurs, que ce soit le tien ou root, et la même chose pour les groupes.

Mais le système Linux, lui, ne se préoccupe pas vraiment de ces noms d’affichages, et utilise en réalité des séquences de chiffres pour gérer tout ça (exactement comme les permissions Unix vues plus haut).

Ainsi, un utilisateur est en réalité identifié par un UID (user identifier) et un groupe par un GID (group identifier).

Ce sont ces ID que tu vois dans les fichiers passwd et shadow, séparés par le caractère « : ».
Le premier ID correspondra toujours à l’UID et le second au GID.

cat /etc/passwd

sudo cat /etc/shadow

Ce sont également ces IDs que tu vois si tu listes les permissions avec ls et l’option -n.

ls -ln

Ces IDs sont utilisés par de nombreux programmes et services, mais tu auras très souvent une version plus parlante à disposition, qui utilisera les noms complets d’utilisateur et de groupe.

Garde cependant en tête ce genre de syntaxe au cas où tu la retrouverais pendant tes voyages.

Exemple

Pour conclure cette courte section, utilisons la commande chmod vue plus haut avec cette syntaxe, pour prouver que tout fonctionne correctement.

mkdir dirtest
chown 0:0 dirtest
ls -l
ls -ln

Comme tu peux le constater, définir 0:0 en argument de chown aura attribué le compte root et le group root en tant que propriétaire de ce répertoire.

Bonus

• A quoi sont réservés les ID entre 0 et 1000 ?
• Que se passe-t’il si deux utilisateurs différents partagent le même UID ?
• Est-ce qu’attribuer l’ID 0 à un compte en fait un compte avec les droits super-utilisateurs ?

Le prochain chapitre c’est par ici… sauf si tu veux te faire un petit café avant.