Il est certaines choses que les utilisateurs n'auront pas besoin de pouvoir faire. Par exemple, il leur est inutile de pouvoir écrire dans le répertoire d'installation d'un programme puisqu'ils stockent leurs sauvegardes et leur configuration dans leur répertoire de travail.
Restreindre ce genre d'accès présente alors plusieurs avantages:
Les utilisateurs seront obligés de sauvegarder dans leur propre répertoire de travail, et ne pourront pas garder d'éventuelles mauvaises habitudes prises sur des systèmes moins orientés multi-utilisateurs. Les sauvegardes des données des utilisateurs seront alors plus faciles à mettre en place.
Un utilisateur ne pourra pas effacer par erreur un fichier nécessaire à un programme ou à un fichier système.
Un attaquant ayant obtenu un accès utilisateur sur la machine aura moins de possibilités pour étendre son accès.
Dans les environnements Unix, le compte administrateur (root) peut absolument tout faire. Il est alors très tentant pour l'administrateur d'utiliser ce compte en permanence, pour ne pas être embété par ces problèmes de droits.... Après tout, l'administrateur est formé à la sécurité informatique, et ne se laissera pas piéger par les attaquants éventuels....
Mais connaitre les principes de base de la sécurité ne protège pas de tout. Certains programmes que vous utilisez peuvent avoir des failles, qui seront peut-être exploitées sur votre machine avant que vous en ayez connaissance, ou vous ferez peut-être un malencontreux rm -rf /*[1] au lieu du rm -rf *[2] que vous vouliez faire.
De plus, certains environnements peuvent nécessiter un découpage strict des droits, incompatible avec la notion de super-utilisateur.
Il existe deux solutions face à ce problème. La première, qui devrait être apliquée sur toute machine (au moins en production), est de se créer un compte utilisateur, et de ne prendre les droits du root que lorsque cela est nécessaire. Cela peut paraitre contraignant mais protège souvent de mauvaises surprises.
La seconde solution est d'utiliser des access lists et/ou des patches spécifiques qui permettent de limiter les droits du root, comme la section intitulée Linux Intrusion Detection System dans Chapitre 8. Il vous sera alors possible de créer des administrateurs limités, ayant seulement accès à certaines taches d'administration. Cette délégation est également faisable par l'intérmediaire de programmes la section intitulée le bit SUID, mais cette solution est souvent délicate à mettre en place.
Le système classique de gestion des droits des fichiers et répertoires sous UNIX propose la possibilité de positionner trois attributs (lecture, écriture, exécution) à trois catégories d'utilisateurs: le propriétaire, le groupe propriétaire et ceux qui ne font partie d'aucune des deux premières catégories.
Quand un utilisateur exécute un programme, celui ci dispose des droits de l'utilisateur l'ayant exécuté. Dans certains cas, il peut être nécessaire à un programme de disposer de droits particuliers, droits que l'on ne désire pas donner aux utilisateurs en dehors de ce contexte.
C'est dans ce genre de situations qu'il est parfois nécessaire d'activer le bit SUID. En plus d'autoriser l'exécution du programme, cet indicateur spécifie au système que le programme doit fonctionner avec les droits du propriétaire du programme, et non ceux de l'utilisateur l'ayant appelé.
Si ce méchanisme peut être fort pratique pour aider à controller les droits d'accès (les utilisateurs n'ont accès à ces ressources qu'au travers d'un programme dont on controlle normalement les actions), il est encore plus important de s'assurer que les programmes utilisant cette option ne disposent pas de faiblesses dans leur conception. En effet, l'exploitation d'une faille dans un programme SUID donnerait accès aux ressources du propriétaire du programme.
Il faut donc préter une attention particulière à tous les programmes utilisant le bit SUID, et en particulier aux programmes SUID root: l'exploitation d'une faille dans un de ces programmes permettrait d'obtenir les droits du root, donc un accès complet au système.
Les Acces List (ACL) proposent une gestion plus fine des droits d'accès aux fichiers et répertoires: il est alors possible de spécifier des droits différents sur un fichier à plusieurs utilisateurs et/ou plusieurs groupes. Cette fonctionnalité est généralement pratique, mais pas nécessaire, et il existe des contextes où une telle gestion des permissions est indispensable.
Le support des ACL n'est pas fourni par défaut sur un noyau Linux. Il existe cependant plusieurs projets proposant cette fonctionnalité. Voyez la section intitulée Patches de sécurité dans Chapitre 8 pour une présentation des plus courants.
| [1] | Cette commande efface toute l'arborescence du système. |
| [2] | Cette commande efface toute la sous-arborescence du répertoire courant. |
| Précédent | Sommaire | Suivant |
| Les mots de passe | Niveau supérieur | Limiter les ressources des utilisateurs |