PratiquePratique
Linuxiens et Linuxiennes, bienvenue au petit bouillon de culture Unix habituel. Cette fois, nous allons étudier la gestion des permissions et des droits.
Lorsque vous possédez un compte sur une station Unix (comme la vôtre), le système ne vous connaît pas par votre nom mais par votre User IDentificator (UID), numéro qui vous est attribué au moment de la création du compte: rappelez vous, lorsque vous avez utilisé la commande adduser, on vous demandait d'entrer l'UID de l'utilisateur créé en vous proposant un UID non encore attribué.
En plus des utilisateurs, Unix gère également la notion de groupe: chaque groupe, identifié bien sûr par son Group IDentificator, définit simplement un ensemble d'utilisateurs (c'est à dire un ensemble d'UIDs). Lorsque vous créez un compte, on vous propose également de choisir le GID du groupe auquel appartient l'utilisateur. Il y a plusieurs écoles: certains préconisent qu'il faut créer un groupe pour chaque utilisateur, d'autres disent de rassembler tous les utilisateurs dans un groupe dédié, appelé par exemple users.
L'UID et le GID de chaque utilisateur sont stockés dans le fichier /etc/passwd (vous pouvez y jeter un coup d'oeil). Lorsque vous vous "loguez", le système d'authentification va consulter ce fichier pour vérifier la validité de votre nom et de votre mot de passe et en cas de succès, il renvoie l'UID et le GID de l'utilisateur autorisé à se connecter. Ce fichier est d'ailleurs celui qui définit le nom de l'utilisateur: vous pouvez renommer un utilisateur en éditant ce fichier (mais ne modifiez surtout pas son UID!)
Un utilisateur peut bien évidemment appartenir à plus d'un groupe. A cette fin, le fichier /etc/group contient, pour chaque groupe, son GID et les noms d'utilisateurs membres (sauf ceux déclarés par défaut dans /etc/passwd).
Il faut savoir qu'à tout moment, chaque fichier, chaque tâche, chaque périphérique, chaque ce que vous voulez possède exactement un UID et un GID (les puristes me pardonneront cet amalgame, les EUIDs et autres subtilités sont hors de propos ici). Nous allons maintenant voir comment on utilise tout ceci pour gérer la sécurité. Encore une petite remarque au passage: les UID et GID de valeur 0 sont ceux dont les droits ne sont pas vérifiés et sont par conséquent réservés au root. Vous pouvez donc changer le nom du root en modifiant le nom associé à UID 0, ce qui est vraiment une très mauvaise idée!
Nous avons vu que chaque fichier (entre autres) possède un UID et un GID. Pour s'en convaincre, il suffit de taper ls -l. Comme ls est sympa, il vous affiche directement le nom de l'utilisateur et du groupe qui correspondent à l'UID et au GID plutôt que les valeurs numériques. L'UID du fichier est ce qu'on appelle habituellement le "propriétaire" du fichier et le GID du fichier le "groupe" du fichier. Il faut d'ailleurs bien comprendre que ces deux champs sont indépendants: un fichier peut très bien faire partie d'un groupe dont le propriétaire n'est pas membre.
Lire l'UID et le GID d'un fichier, c'est bien, mais il faut aussi pouvoir les modifier. A cette fin, on dispose de deux commandes: chown et chgrp
Chown (CHange OWNer) permet (entre autres) de modifier le propriétaire d'un fichier. La syntaxe générale est:
chown <nom_du_propriétaire> <liste de fichiers>.
Si ça vous amuse, vous pouvez entrer directement l'UID au lieu du nom et faire beaucoup d'autres choses (voir man). En clair, cette commande permet de donner un fichier à quelqu'un d'autre. Toutefois, seul le root peut l'utiliser, les simples utilisateurs n'ont aucun autre moyen de se débarrasser d'un fichier que de l'effacer.
La commande chgrp (CHange GRouP) est symétrique:
chgrp <nom_du_groupe> <fichiers>
Elle vous permet de modifier le groupe d'un fichier. Contrairement à chown, elle peut être appelée par un simple utilisateur, à condition qu'il soit membre du groupe auquel il veut donner le fichier. Le root n'a naturellement aucune restriction de ce type.
Bon, tout ça c'est bien joli, mais en ce qui concerne la gestion des droits, on n'a pas avancé d'un poil. On ne sait toujours pas comment autoriser Arnold Schwarzenegger à jouer à Xpilot et comment au contraire en empêcher Claudia Cardinale. Pas de panique, on y arrive.
L'inode de chaque fichier (cf. article sur les liens) contient un champ dont les bits définissent qui peut faire quoi avec ce fichier. On va d'abord s'intéresser à trois d'entre eux:
- le bit R comme Read: s'il est armé, la lecture est autorisée, désarmé, il interdit de lire le fichier.
- le bit W comme Write: il contrôle de la même manière l'écriture sur le fichier et la possibilité de le supprimer.
- le bit X comme eXecute: pour un fichier, il contrôle la possibilité de l'exécuter (si c'est un exécutable ou pas, en gros). Pour un répertoire, il permet ou il interdit l'accès à ce répertoire.
Il est clair que certaines combinaisons n'ont pas de sens: par exemple un fichier avec W armé et R et X désarmés ne peut être que modifié ou effacé, mais pas lu ni exécuté, ce qui est "vachement utile!" De même X armé et R désarmé vous donnent un fichier que vous pouvez certes exécuter après l'avoir chargé, mais vous ne pouvez pas le charger, car il n'est pas lisible...
Et on arrive maintenant à un point crucial. En fait, chaque fichier possède trois bits R, trois W et trois X, ce qui fait neuf en tout. Le premier trio RWX définit les permissions pour le propriétaire du fichier (c'est à dire pour toute tâche dont l'UID correspond à l'UID du fichier), le second pour tous les utilisateurs membres du groupe auquel appartient ce fichier, et enfin le troisième pour tous les autres. Vous pouvez voir ces bits si vous faites ls -l.
Vous savez maintenant comment sont déclarés les droits des utilisateurs, mais il faut encore pouvoir modifier les bits de permissions à votre convenance. C'est le rôle de la commande CHange MODe (chmod). Cette commande est assez complexe (et plus encore lorsu'il s'agit du GNU chmod que vous avez sous Linux) et nous ne l'aborderons que de manière simplifiée.
La syntaxe générale est chmod <permissions> <fichiers>.
Certains aiment encore entrer les permissions sous forme de nombres octaux, mais on va s'intéresser plutôt à la forme symbolique. La forme symbolique a la forme [qui]+/-[quoi]. Je m'explique:
Quoi définit simplement la combinaison de permissions concernées: r, w, x... Qui peut avoir les valeurs suivantes:
Quelques exemples clarifieront la chose:
Vous pouvez également utiliser la lettre a, qui est un raccourcis, pour ugo: chmod a+r permet à tout le monde de lire le fichier.
Voilà, vous pouvez maintenant décider qui pourra faire quoi sur votre système!
Ceux qui suivent (et ne connaissant pas Unix) sont peut être en train de méditer sur un problème épineux: supposons que vous exécutez un programme dont vous n'êtes pas le propriétaire. On peut se dire que si le programme appartient à Marcello Mastroianni, il aura les mêmes droits que ce dernier, un point c'est tout! Mais on peut aussi penser que puisque c'est Charlie Chaplin qui l'exécute, il aura les droits de ce dernier, après tout! En réalité, que se passe-t-il?
Chaque fichier possède un bit setuid qui permet de résoudre le dilemme. Lorsqu'on exécute un programme dont le setuid est désarmé (=par défaut), il hérite l'UID de la tâche qui l'a lancé, par exemple le shell de Charlie. En revanche, lorsque ce bit est armé, alors le programme s'exécutera toujours avec l'UID de son propriétaire.
Par exemple, lorsqu'un utilisateur utilise la commande passwd pour changer son mot de passe, il faut répercuter le changement dans le fichier /etc/passwd, qu'aucun utilisateur n'a le droit d'écrire. Mais le programme passwd appartient au root et son setuid est mis, donc la modification peut se faire.
Il est inutile de préciser que le setuid doit être manipulé avec une extrême prudence. Imaginez les effets désastreux d'un shell appartenant au root avec un setuid armé. Il suffirait à un utilisateur de lancer ce shell pour obtenir les droits du root!
Ah oui, j'allais oublier: utilisez chmod +s machin pour armer le bit setuid du fichier machin et chmod -s machin pour le désarmer.
Comme d'habitude, vous pouvez m'envoyer vos remarques et commentaires. On se verra le mois prochain, en attendant, sécurisez bien votre machine!
Jakub Zimmermann
zimmerma@ie2.u-psud.fr