- Imprimer –
- Dernière modification le 2 mai 2013
Nouveau concept de sécurité
Contents
Introduction
L'un des problèmes fondamentaux des UNIX réside dans la sécurité. L'objectif des hackeurs est d'obtenir le compte du super utilisateur (root) pour avoir tous les pouvoirs sur la machines. Pour se faire, il y a deux solutions :
- Exploiter une faille du noyau
- Exploiter la faille d'un programme tournant avec les privilèges du super utilisateur
Dans le premier cas, mis à part corriger les bugs et faire attention lors du développement du noyau, il n'y a pas grand chose d'autre à faire. Cependant, pour le second point, il est naturellement possible de corriger les bugs mais une autre solution réside dans le fait de supprimer les programmes tournant en root !
Enfin, pour les tâches d'administrations, il est nécessaire d'utiliser le compte du super utilisateur. Cependant, il est bien trop facile d'exécuter bien plus de commandes que nécessaire pour effectuer une tâche d'administration comme par exemple lancer un navigateur internet pour rechercher une documentation sur la manière de configurer un fichier. Tous ces programmes n'ayant pas reçu une attention vraiment particulière comme sshd, sur la sécurité, ils sont plus facilement faillible et peuvent donc causer beaucoup de dégâts.
Nouvelle gestion des privilèges
Privilèges d'administration
Ce nouvel aspect des choses peut choquer toutes les personnes du monde UNIX qui ont l'habitude d'une hiérarchie assez simple : un administrateur et le reste est composé d'utilisateurs. Pourtant, certains utilisateurs pourraient avoir un rôle à jouer dans l'administration d'une machine. L'objectif est donc de dispatcher les droits du super utilisateur root sur d'autres comptes où ces privilèges ne seraient pas au complet mais limités.
Pour être plus précis, il pourrait être possible d'associer à un compte le droit de gérer les utilisateurs d'une machine, le droit de gérer les paquetages présents, le droit de modifier le pare-feu ; le tout sans pour autant utiliser le compte root. L'intérêt peut être rapidement schématisé dans le cas d'une société. Par exemple, Huguette possède une machine. Elle en est la propriétaire et pourtant elle ne veut pas s'occuper de toute la partie administrative. Elle lègue donc un compte à Richard, l'administrateur informatique, pour s'occuper de la gestion et la mise à jour des programmes ; sans oublier un compte à Charles, le responsable sécurité informatique de la société, qui est chargé de la sécurité de la machine d'Huguette. Quant à elle, elle se donne le droit de gérer les utilisateurs pour autoriser ou non, suivant son humeur, ses collègues Marie, Véronique et Joseph d'utiliser sa machine. Bien entendu, ces privilèges étendu ne seront pas donné aux comptes utilisateurs de tous ces protagonistes mais sur des comptes à part qui auront été créés à l'occasion comme par exemple : admin (pour gérer les utilisateurs), mainteneur (pour gérer les paquetages) et sécurité (pour gérer la sécurité de la machine). Et même si Richard et Charles ont des privilèges étendus sur la machine de Huguette, elle peut dormir tranquille sachant que ça ne leur confèrera pas le droit d'aller trifouiller dans sa base kwalletmanager pour lui voler ses mots de passes !
Privilèges pour les services
Du point de vue des programmes, le fonctionnement est le même. L'objectif est donc de faire éclater les privilèges du root pour conférer ceux qui sont nécessaire aux pseudo-utilisateurs sous lesquels tourneront les services critiques. À ce titre, il est donc nécessaire d'analyser les besoins de chacuns d'eux pour savoir comment répartir ces droits.
Si nous prenons l'exemple des services comme : getty, sshd, {kgx}dm, ceux-ci n'ont besoin que d'une faible partie des privilèges root : ils ont besoin de pouvoir créer des terminaux virtuels (/dev/pty..) (pour sshd principalement) et d'exécuter le terminal, la commande ou n'importe quel autre programme, sous l'utilisateur, une fois le mot de passe vérifié. À ce titre, il pourrait être envisagé que les programmes n'aient pas à vérifier eux-même ces mots de passes mais qu'ils soient utilisés comme passe, fourni au noyau, dans une nouvelle procédure système, pour charger le programme désiré. Le noyau, via un appel à un greffon externe au noyau (pour permettre de modifier à loisir les systèmes de vérifications suivant les besoins), contrôle le mot de passe et s'il est valable ; alors effectue un fork du programme précédent (On pourrait donc imaginer une procédure système comme : forkToUser(const char *username, const char *password); Une fois le fork effectué, il ne reste plus qu'un simple execve à faire.
sshd et tous les autres n'auraient plus besoin de tourner en root et pourraient tourner sous des utilisateurs différents. Au final, si une faille est trouvée et exploitée dans ces services, l'auteur gagnera les privilèges associés à ces services qui ne lui permettront guère de faire grand chose sinon de supprimer les fichiers de configuration de sshd.....
Le root existe toujours
Attention, ceci n'est pas destiné à faire disparaître l'utilisateur root. Celui-ci existera toujours mais ne sera plus utilisé de manière aussi intensive qu'actuellement. Celui-ci ayant des accès à /dev/kmem etc., il est crucial de le confiner pour des opérations beaucoup moins fréquentes que ce qui est actuellement. Le tout protégeant d'autant les machines et évitant au maximum les risques liés à des dérapages de commandes.
Des idées d'implémentation
Il est possible de baser ce principe sur des appartenances à des groupes, pour la majorité des cas. Par exemple, si l'utilisateur sshd qui fait tourner le service du même nom fait parti du groupe "secureport" (accès aux ports 1 - 1024) et "termmgt" (création de terminaux), il aura les privilèges que le noyau accorde à ces groupes. Pour ce qui est de l'administration de la machine, deux solutiions. Soit un principe comme sudo permet d'associer des commandes spécifiques à des comptes spécifiques, soit le principe précédent basé sur des groupes et des commandes possibles associées à ces groupes sera utilisé.