Aujourd’hui on va faire une petite pause sur les certificats (j’en ai marre d’en parler mais je n’ai pas encore dit mon dernier mot à leur sujet ; on y reviendra dans quelques semaines) et aborder un sujet beaucoup plus basique : celui des permissions.

Il est très important de bien comprendre cette notion, assez simple en soit, car il en découle de nombreuses choses qui peuvent avoir de lourds impacts sur la sécurité de vos machines.

Pour cet article introductif, on va rester sur du très basique. On développera les subtilités sous-jacentes dans des articles futurs.

Sauf mention contraire, ce que je vais décrire concerne les systèmes Linux mais les choses sont assez similaires avec Windows. Je laisse le lecteur creuser de son côté s’il souhaite des précisions pour cet OS.

Permissions : pour quoi faire ?

C’est le mien…

Supposons que vous partagiez votre machine avec d’autres utilisateurs. Typiquement vous allez vous créer des comptes différents afin de disposer chacun de votre propre espace de travail et de vos propres fichiers. A partir de là, vous vous attendez – et c’est plutôt légitime – à ce que les autres utilisateurs ne puissent pas accéder à vos dossiers et fichiers personnels et réciproquement.

… Mais je suis partageur …

Par contre il y a peut-être un ou deux fichiers par-ci par-là pour lesquels ce n’est pas si tranché : le scan pdf du classeur de recettes de tartes à la mayonnaise de Mamie Jaqueline – pour lequel vous aimeriez que les autres utilisateurs aient un accès en lecture – ou encore le plan de votre base secrète Minecraft que vous aimeriez partager en lecture et écriture avec tous les geeks qui utilisent cette machine pour que chacun puisse y contribuer.

… Et Je veux que machine fonctionne …

Au-delà des simples utilisateurs humains de votre machine, vous voulez a priori que l’OS fonctionne correctement et que les applications que vous installez aient elles aussi leur comportement attendu. Pour ce faire, elles auront besoin de pouvoir lire et écrire certains fichiers liés aux utilisateurs (fichiers de configuration par exemple), ou des ressources partagées avec d’autres programmes.

… sans risque !

Pour autant, on ne peut pas laisser les applications libres de lire et écrire tous les fichiers de notre système : cela faciliterait certes grandement les choses mais cela rendrait notre machine très vulnérable. En effet, n’importe quelle application – typiquement un virus – pourrait exécuter arbitrairement du code pour lire et écrire nos fichiers.

Comment ça marche ?

Lire, écrire et exécuter

Pour que tout ceci fonctionne sans que cela soit une énorme prise de tête, les systèmes utilisent des règles, appelées permissions, qui permettent de définir qui peut faire quoi sur tel ou tel fichier ou dossier.

On articule alors les permissions de chaque entité de votre système selon plusieurs axes : lecture, écriture et exécution.

Ces permissions sont assez claires lorsqu’on parle de fichiers : je peux le lire, modifier son contenu ou l’exécuter lorsqu’il s’agit d’un exécutable (no shit !), mais sont un peu plus subtiles lorsqu’on parle d’un répertoire :

• les droits d’écriture autorisent à créer des fichiers et sous-dossiers à l’intérieur du répertoire en question
• les droits en lecture autorisent à lister le contenu du répertoire
• les droits d’exécution autorisent à traverser le répertoire, autrement dit à se placer dedans ou dans un de ses sous-dossiers et à lire le contenu des fichiers qui se trouvent dedans

On peut donc très bien avoir un répertoire dont on peut lister le contenu mais sans pour autant pouvoir le lire… et inversement !

Donc là vous devez vous dire “Ok, super ! Mais bon si je dis que tel fichier est en écriture, tout le monde peut le modifier ?! J’ai pas l’impression qu’on répond à nos problématiques là ! “. Pas faux, si les permissions étaient valables pour l’ensemble des utilisateurs de la machine, on n’irait pas bien loin avec ça. Pour pousser l’idée à un niveau utile, il faut la couper à la notion de propriété.

Propriété des ressources

Pour chaque fichier de votre système Linux on a la notion d’utilisateur propriétaire et de groupe propriétaire. Pour afficher ces informations je vous invite à utiliser la commande ls avec l’option -l (dans les faits j’utilise -al pour afficher aussi le répertoire courant et le répertoire parent ainsi que les fichiers et dossiers cachés).

> ls -al
drwxr-xr-x  3 prims devs 4096 Jun 27 14:51 .
-rw-rw-r--  1 prims devs    0 Jun 27 14:51 bar
drwxr-xr--  2 prims devs 4096 Jun 27 14:51 foo
drwxr-xr-x 23 prims devs 4096 Jun 27 14:50 ..

Ici on voit que l’ensemble des fichiers et répertoires appartient à l’utilisateur “prims” et au groupe “devs”.

Notez si vous n’avez pas encore l’habitude de travailler en ligne de commande que “.” désigne le répertoire courant et “..” le répertoire parent.

Notez également que pour les systèmes Windows on a seulement la notion d’utilisateur propriétaire et pas celle de groupe propriétaire.

Les permissions à proprement parler

Dans le résultat de la commande ls ci-dessus, on a au début une suite de 10 caractères qui peuvent être ‘-‘, ‘d’, ‘r’, ‘w’ ou ‘x’ (il est aussi possible de trouver ‘s’ mais on reviendra à ça dans un autre article plus poussé concernant les permissions).

Ces caractères se décomposent comme suit :

• type d’entité : ‘-‘ pour un fichier, ‘d’ pour un répertoire (directory)
• droits pour l’utilisateur propriétaire
• droits pour les membres du groupe propriétaire
• droits pour les utilisateurs qui n’entrent dans aucune des deux catégories précédentes

Chaque groupe de droits est dans l’ordre lecture, écriture, exécution et contient soit un ‘-‘ pour signifier que le droit est absent, soit une lettre significative (dans la langue de Willy-Will) du type de droit pour signifier sa présence : r pour read, w pour write, x pour execute.

Si on dépouille encore une fois le résultat de notre commande ls, on a donc :

• le répertoire courant et le répertoire parent avec un contrôle total pour l’utilisateur “prims” mais pas d’écriture possible pour les membres du groupe “devs” et les utilisateurs lambda
• le contenu du répertoire “foo” (premier caractère = ‘d’) peut être listé par tout le monde mais seuls “prims” et les “devs” peuvent traverser ce dossier et seul “prims” peut y créer de nouvelles entités
• le fichier “bar” (premier caractère = ‘-‘) ne peut être exécuté par personne (ce n’est donc tout simplement pas un exécutable) et peut être lu par tout le monde mais seul “prims” ou un membre du groupe “devs” pourra le modifier.

Sous Windows, c’est un peu différent : l’utilisateur propriétaire d’un fichier ou dossier (consultable dans “Propriétés > Sécurité > Avancé”) a forcément le contrôle total sur celui-ci. Par contre, tous les groupes qui existent sur la machine peuvent avoir leur propre jeu de droits sur chaque fichier ou dossier. Cela permet une gestion plus fine des permissions que sous Linux mais en même temps cela peut engendrer une grande complexité de paramétrage.

Le trop est l’ennemi du sûr

Pour des raisons de sécurité informatique, il est toujours préférable que chaque utilisateur ou groupe n’aient accès qu’au strict minimum dont il a besoin, ce qui est d’ailleurs valable pour l’ensemble de votre gestion des permissions, pas seulement celle de vos fichiers (accès aux tables dans une base de données, accès aux vhost dans un broker AMQP, etc.).

Vous remarquerez que par défaut, la plupart des systèmes Linux vous créent les nouveaux fichiers (touch) avec les droits “-rw-r–r–” et les nouveaux répertoires (mkdir) avec les droits “drwxr-xr-x”, vous laissant ainsi seul à pouvoir faire des écritures. C’est plutôt bien, mais il convient de réfléchir à deux fois avant de laisser ces valeurs par défaut. En effet, si vous créez un fichier sensible – qui stocke des hash de mdp par exemple – il devient logique d’enlever la lecture pour les utilisateurs lambda, voire même pour le groupe propriétaire si ces informations ne concernent que vous.

Je vous invite à faire les manipulations décrites dans l’article sur les certificats autosignés, à regarder les droits qui sont donnés aux fichiers de sortie par openssl et à vous demander pourquoi. Cela devrait illustrer parfaitement l’utilité de la gestion des permissions et sa très forte adhérence avec la sécurité informatique.