Lorsque vous utilisez un système GNU/Linux, il faut maîtriser plusieurs aspects concernant son fonctionnement et plus particulièrement les permissions sur les fichiers et répertoires. Tout cela se fait à l’aide du terminal.
Petit rappel, sous Linux vous avez la possibilité de créer autant d’utilisateurs que vous le souhaitez. Il y a un utilisateur très particulier avec lequel, vous avez tous les droits et permissions (root).
Pourquoi est-il important de connaître ou de gérer les permissions sur des fichiers et/ou répertoires ?
La raison est très simple ! Si par erreur vous donnez tous les droits ou suffisamment de droits concernant un document ou dossier, vous pourrez alors corrompre votre sécurité si ces derniers sont ou comportent des informations sensibles. Par exemple un hacker qui réussit à pénétrer votre système peut modifier les fichiers qui ont certaines permissions dédiées à l’utilisateur en question.
Un peu de théorie ne nous fera pas de mal :
Comme vous le savez sous Linux, tout est un fichier, y compris les répertoires et les périphériques qui ont des autorisations pour autoriser ou restreindre certaines opérations. Donc, lorsque vous définissez une autorisation pour un fichier, vous devez connaître les utilisateurs Linux auxquels vous autorisez ou restreignez les trois autorisations.
Les utilisateurs
Un fichier sous linux appartient à un utilisateur et à un groupe. Il existe trois types d’utilisateurs différents :
- u (pour user) : l’utilisateur auquel appartient les fichiers ou répertoires
- g (pour group) : le groupe auquel appartient les fichiers ou répertoires
- o (pour other) : les autres utilisateurs
Les droits basiques
Plusieurs permissions peuvent être appliquées sur les fichiers/dossiers :
- r (pour read) : droit de lire
- w (pour write) : droit de modifier ou droit d’écriture
- x (pour execute) : droit d’exécuter le fichier
- – (pour rien) : aucun droit sur le fichier ou répertoire
Parfois vous verrez la lettre d devant, cela veut tout simplement dire qu’il s’agit d’un répertoire (directory).
Avez-vous prêté attention lorsque vous utilisez la commande ls -l ou ls -la ? Eh bien faites-le et observez la première colonne. Vous allez voir qu’il s’agit des droits (permissions) :
Gestion des droits
Pour attribuer des permissions sur les fichiers/dossiers, il convient de bien agencer utilisateurs et droits. Pour donner les droits à l’utilisateur en lecture/écriture sur un fichier, il suffit d’utiliser la commande : chmod
Exemple : chmod u=rwxr g=xr o=x exemple.txt
Il y a aussi la notation en octale, reprenons l’exemple ci-dessus en représentation octale :
chmod 755
Tableau récapitulatif :
| Aucun droit | – – – | 0 |
| Exécution seulement | – – x | 1 |
| Ecriture seulement | – w – | 2 |
| Ecriture et exécution | – w x | 3 |
| Lecture seulement | r – – | 4 |
| Lecture et exécution | r – x | 5 |
| Lecture et écriture | r w – | 6 |
| Lecture, Ecriture et Exécution | r w x | 7 |
Si vous donnez tous les droits à un fichier vous obtiendrez : rwx-rwx-rwx (777).
Il faut bien comprendre que ces droits sont décomposés en 3 parties comme nous l’avions vu au début de cet article. Regardons maintenant à quoi ça correspond :
Les droits spéciaux
On vient de voir les permissions des fichiers/répertoires. Vous savez qu’en complément il existe 3 droits spéciaux :
- SUID
- SGID
- Sticky Bit
Ces permissions sont également attribuées avec la commande chmod. Elles peuvent aussi être définies en octale, on les place alors devant les permissions comme ceci:
- SUID
Le SUID qui veut dire Set User ID, est un droit qui s’applique uniquement à des fichiers et non à des répertoires. Mais il y a un concept important à comprendre, lorsque vous exécutez un script/fichier vous réalisez cette tâche avec les droits du UID (User ID) actuel, en gros avec l’utilisateur en question.
Par conséquent, il y a certaines actions qui ne sont pas disponibles en fonction des fichiers avec les droits d’utilisateur (écrire dans un document appartenant à root). Voyons un exemple pour clarifier les choses :
Pour changer son mot de passe on utilise la commande passwd, mais pour que cela soit effectif en tant que user nous devons pouvoir écrire sur /etc/passwd et /etc/shadow alors qu’il ne nous est pas permis.
C’est le SUID qui va nous permettre l’action précédente. Oui mais comment on peut le savoir ? Allez voir les droits du fichier passwd avec la commande : ls -l /usr/bin/passwd
Notez ici qu’il y a un s à la place du x, donc nous avons les droits pour modifier un mot de passe car le script passwd a les autorisations SUID.
Maintenant comment je peux accorder ce droit à un autre fichier ?
Ce n’est pas compliqué, il existe deux façons de le faire. Plutôt deux commandes, voici un exemple:
- chmod u+s /usr/bin/passwd
- chmod 4755 /usr/bin/passwd (notation octale)
Ici le 4 correspond au bit SUID, vous savez qu’il est possible aussi d’enlever ce dernier avec la commande :
- chmod u-s /usr/bin/passwd
Cela étant dit, comment je peux retrouver les fichiers avec les permissions SUID ?
Rien de plus simple, voici la commande : find / -perm -u=s -type f 2>/dev/null
- /: la racine du système de fichiers et trouve chaque répertoire
- -perm: indique la recherche des autorisations qui suivent
- -u=s: les fichiers appartenant à l’utilisateur root
- -type: le type de fichier que nous recherchons
- f: désigne un fichier normal, pas les répertoires ou les fichiers spéciaux
- 2: désigne le deuxième descripteur de fichier du processus, c’est-à-dire stderr (erreur standard)
- >: signifie redirection
- /dev/null: est un objet de système de fichiers spécial qui supprime tout ce qui y est écrit
- SGID
Contrairement au SUID, le SGID, s’applique aussi bien aux fichiers qu’aux répertoires. En ce qui concerne les fichiers, rien ne change.
SGID, signifie : Set Group ID
En revanche, il faut savoir qu’un utilisateur qui lancerait un script lui appartenant mais avec des droits SGID, s’exécuterait alors avec les droits du groupe auquel il appartient.
Par exemple un script appartenant au groupe root, pourrait écrire/lire dans des fichiers ou répertoires inaccessibles à l’utilisateur en temps normal. Vous voyez la nuance ?
Bon, c’est compris pour les fichiers mais comment ça se passe pour les répertoires ?
Eh bien, à vrai dire c’est complétement différent ! On ne parle pas de droits d’exécution mais d’appartenance. Par exemple, si dans un répertoire appartenant à un groupe (avec droits SGID) plusieurs fichiers et/ou sous répertoires sont créés par un utilisateur, alors ces fichiers appartiendront à ce groupe d’utilisateurs.
C’est une méthode pratique pour un travail en groupe. Imaginons que vous êtes trois utilisateurs à travailler sur un même répertoire contenant des fichiers, alors il serait plus classe d’attribuer les droits SGID que d’utiliser la commande chmod 777 (tous les droits).
Exemple :
Notez ici qu’il y a un s à la place du x pour le groupe de permissions du groupe (parrot). Sa valeur octale est 2. Les droits du répertoire essai sont donc 2755.
Oui mais comment puis-je accorder ces droits ?
La commande ressemble à celle du SUID, avec une légère différence :
- chmod g+s essai/
- chmod 2755 essai/
Voici la commande pour trouver les fichiers avec les permissions SGID :
find / -perm -g=s -type f 2>/dev/null
Attention !
Ces autorisations spéciales présentent un risque de sécurité. Certains utilisateurs déterminés peuvent trouver un moyen de conserver les autorisations qui leur sont accordées par le processus setuid même lorsque le processus a terminé de s’exécuter.
Vous devez surveiller votre système pour toute utilisation non autorisée des droits setgid pour obtenir des privilèges de superutilisateur (root). Des autorisations suspectes accordent l’accès de groupe à un tel programme à un groupe inhabituel plutôt qu’à root ou bin.
- STICKY BIT
Le Sticky Bit, peut s’appliquer comme le SGID aux fichiers (binaires) et aux répertoires. Avec un petit plus, cette méthode garde en mémoire un exécutable même si le programme qui a fait appel à ce dernier est terminé (c’est pourquoi on l’appelle « Sticky » qui veut dire collant en anglais).
Cette méthode n’est plus utilisée de nos jours avec la révolution des ordinateurs super puissants, à l’époque avec des machines moins puissantes elle était très utile car en positionnant le Sticky Bit sur un exécutable on le gardait dans le swap et il permettait au système de le charger plus rapidement.
À l’inverse, elle sert toujours pour les répertoires et s’avère très importante. Le Sticky Bit permet d’interdire la suppression d’un répertoire et/ou son contenu par quiconque n’étant pas propriétaire, puissant non ?
L’exemple très connu sous les systèmes UNIX est le répertoire /tmp, sur ce dernier n’importe quel utilisateur du système peut créer ou supprimer des fichiers ou des dossiers dans /tmp, mais il ne pourra pas supprimer ceux créés par un autre utilisateur. Ceci est permis grâce au positionnement du STICKY BIT.
Ce qu’il faut retenir sur cette méthode, c’est qu’il protège les fichiers d’un répertoire.
Allons voir les droits de ce répertoire :
Ici le t à la fin remplace le x pour le groupe de permissions des autres. Sa valeur octale est 1.
Pour positionner le STICKY BIT il existe 2 commandes, identiques à celles que nous avons vues au-dessus avec une petite différence également :
- chmod 1777 /tmp
- chmod o+t /tmp
Exemple :
Commandes : mkdir partage et chmod o+t partage/
Voilà pour l’explication des permissions et droits spéciaux sous GNU/Linux.
Conclusion :
- Les droits SUID et SGID doivent être utilisés avec beaucoup de précaution car ils peuvent être la cause d’escalade de privilèges. La meilleure façon d’éviter une catastrophe est de les garder pour certaines applications nécessaires (à vérifier en fonction du besoin et bon fonctionnement). Il est préférable d’utiliser les programmes su et sudo plutôt que ces droits spéciaux.
Si vous souhaitez lister l’ensemble des setuid/setgid présents sur votre système, utilisez la commande suivante :
find / -type f -perm /6000 -ls 2>/dev/null
- Pour le Sticky Bit il est préférable de s’assurer que les dossiers accessibles à tous en écriture appartiennent bien à l’utilisateur root ! afin d’empêcher l’utilisateur propriétaire de pouvoir modifier tout, malgré la présence du Sticky Bit.
Nous sommes arrivés à la fin de cet article, un peu technique mais primordial pour la bonne gestion des fichiers/répertoires et les droits attribués (niveau sécurité). Si il y a des points incompris n’hésitez pas à me contacter ou de laisser un commentaire. De plus si vous avez des demandes particulières sur d’autres points faites-moi signe.
À bientôt PEACE !
No responses yet