Principe de moindre privilège
En informatique, le principe de moindre privilège est un principe qui stipule, selon l'ANSSI[1], qu'une tâche ne doit bénéficier que de privilèges strictement nécessaires à l'exécution du code menant à bien ses fonctionnalités. En d'autres termes, une tâche ne devrait avoir la possibilité de mener à bien que les actions dont l'utilité fonctionnelle est avérée.
Ce principe suppose alors que chaque fonctionnalité ne doit posséder que les privilèges et ressources nécessaires à son exécution, et rien de plus. Ainsi en cas de défaillance grave du système, les dommages ne peuvent pas dépasser ce qui est autorisé par les privilèges et les ressources utilisés, ces derniers étant eux-mêmes limités par la séparation de privilège.
Le cas le plus simple à comprendre est celui d'un administrateur qui doit toujours utiliser son compte utilisateur normal lorsqu'il n'a pas besoin d'accéder à des ressources appartenant à l'utilisateur root. Lorsque l'administrateur est obligé d'utiliser le compte root, il doit en limiter le plus possible la durée afin de s'exposer le moins possible à un quelconque problème.
Bénéfices
- Une meilleure stabilité du système : les privilèges étant limités, les interactions entre les différentes applications installées, ainsi que les possibilités qu'une application puisse ralentir ou provoquer un crash système sont aussi limitées.
- Une meilleure sécurité du système : l'exploitation d'une faille dans un logiciel pour prendre le contrôle de la machine (que cette faille ait été découverte dans un logiciel légitime ou introduite par un attaquant : malware, rootkit par exemple) est rendue plus difficile pour un attaquant.
- Une facilité de déploiement accrue : la limitation des privilèges et ressources nécessaires à un logiciel permet de l'installer plus facilement, en évitant notamment les étapes additionnelles liées à l'User Account Control.
Implémentation
La séparation des privilèges est souvent réalisée sur des programmes dont la taille ne permet pas de s'assurer de l'absence de bug par audit de code. Dans ce cas, le programme est divisé en deux processus par l'appel système fork. Le processus contenant la plupart du code non audité va abandonner tous les privilèges et ressources dangereux, alors que le processus réalisant les opérations dangereuses va conserver juste les privilèges et ressources nécessaires à son rôle ; sa taille modeste autorisant un audit de code poussé. Le processus non audité va alors communiquer avec le processus audité pour lui faire réaliser les opérations dont il a besoin.
Dans le cas d'un crash du noyau de système d'exploitation (kernel), qui fonctionne avec un niveau maximal de privilège et qui est notamment chargé de la gestion des composants matériels, l'application du principe de moindre privilège évite qu'un attaquant ayant introduit un cheval de Troie (informatique) puisse usurper le contrôle de l'ensemble des processus du système.
Voir aussi
Articles connexes
- Élévation des privilèges
- Setuid
- OpenBSD, un système d'exploitation faisant grand usage de la séparation des privilèges.
- Sandbox (sécurité informatique)
- User Account Control
- sudo
Liens externes
- Mesures de sécurité dans OpenBSD (lien en anglais, très bonne introduction à la séparation des privilèges, Présentation de Theo de Raadt)
- The Protection of Information in Computer Systems (article de J.H. Saltzer and M. D. Schroeder, en anglais)
Références
- ANSSI, « RECOMMANDATIONS POUR LA MISE EN PLACE DE CLOISONNEMENT SYSTÈME », Guide ANSSI, (lire en ligne)