DOCS/UNIX/SElinux : Différence entre versions
| Ligne 5 : | Ligne 5 : | ||
Security-Enhanced Linux (SELinux) est un mécanisme de sécurité à contrôle d'accès obligatoire (MAC) implémenté dans le noyau GNU/Linux. SELinux a été introduit pour la première fois dans Redhat/CentOS 4 et a été considérablement amélioré dans les versions ultérieures. Ces améliorations signifient que le contenu varie quant à la façon d'aborder SELinux au fil du temps pour résoudre les problèmes. | Security-Enhanced Linux (SELinux) est un mécanisme de sécurité à contrôle d'accès obligatoire (MAC) implémenté dans le noyau GNU/Linux. SELinux a été introduit pour la première fois dans Redhat/CentOS 4 et a été considérablement amélioré dans les versions ultérieures. Ces améliorations signifient que le contenu varie quant à la façon d'aborder SELinux au fil du temps pour résoudre les problèmes. | ||
| + | |||
| + | ===Quelques-uns de problème de sécurité sous Linux=== | ||
| + | |||
| + | Pour bien comprendre pourquoi SELinux est si important et ce qu'il peut apporter, le plus simple est de passer en revue quelques exemples. Sans SElinux activé sur un système GNU/Linux, seules les méthodes traditionnelles de contrôle d'accès discrétionnaire (DAC) telles que les autorisations sur les fichiers/répertoires ou les listes de contrôles d'accès (ACL) sont utilisées pour contrôler l'accès des utilisateurs aux ressources fichiers. Les utilisateurs et les programmes sont habilités à accorder des autorisations de fichiers non sécurisées à d'autres personnes ou, à l'inverse, à accéder à des parties du système qui ne devraient pas être nécessaires à son fonctionnement normal. Par exemple : | ||
| + | |||
| + | * Les administrateurs n'ont aucun moyen (simple) de contrôler les utilisateurs : Un utilisateur peut définir des permissions de lecture par tout autre utilisateur sur des fichiers sensibles tels que des clés ssh et sur le répertoire contenant ces clés, habituellement : ~/.ssh/ | ||
| + | * Les processus peuvent changer les propriétés de sécurité. Un fichier contenant les mails d'un utilisateur ne devrait être lisisble que par son propriétaire, mais un logiciel de messagerie a la possibilité de changer ses propriétés et les rendre lisibles par tout le monde. | ||
| + | * Les processus héritent des droits des utilisateurs qui les exécutent : Firefox par exemple, s'il est compromis par un '''trojan''', serait en mesure de lire la clé privée de l'utilisateur alors qu'il n'a aucune raison de le faire. | ||
| + | |||
| + | Dans le modèle DAC traditionnel, il existe essentiellement deux niveaux de privilèges, celui de l'utilisateur et celui de l'administrateur root, et il n'y a pas de moyen simple d'appliquer un modèle de moindre privilège. De nombreux processus lancés par root perdent ensuite leurs droits d'être exécutés en tant qu'utilisateur restreint et certains processus peuvent être exécutés dans un 'chroot', mais toutes ces méthodes de sécurité sont discrétionnaires et pas toujours réaliseables. | ||
Version du 11 décembre 2020 à 15:29
SElinux - petit guide de survie sous Redhat/Centos
SELinux ? quesaquo ?
Security-Enhanced Linux (SELinux) est un mécanisme de sécurité à contrôle d'accès obligatoire (MAC) implémenté dans le noyau GNU/Linux. SELinux a été introduit pour la première fois dans Redhat/CentOS 4 et a été considérablement amélioré dans les versions ultérieures. Ces améliorations signifient que le contenu varie quant à la façon d'aborder SELinux au fil du temps pour résoudre les problèmes.
Quelques-uns de problème de sécurité sous Linux
Pour bien comprendre pourquoi SELinux est si important et ce qu'il peut apporter, le plus simple est de passer en revue quelques exemples. Sans SElinux activé sur un système GNU/Linux, seules les méthodes traditionnelles de contrôle d'accès discrétionnaire (DAC) telles que les autorisations sur les fichiers/répertoires ou les listes de contrôles d'accès (ACL) sont utilisées pour contrôler l'accès des utilisateurs aux ressources fichiers. Les utilisateurs et les programmes sont habilités à accorder des autorisations de fichiers non sécurisées à d'autres personnes ou, à l'inverse, à accéder à des parties du système qui ne devraient pas être nécessaires à son fonctionnement normal. Par exemple :
- Les administrateurs n'ont aucun moyen (simple) de contrôler les utilisateurs : Un utilisateur peut définir des permissions de lecture par tout autre utilisateur sur des fichiers sensibles tels que des clés ssh et sur le répertoire contenant ces clés, habituellement : ~/.ssh/
- Les processus peuvent changer les propriétés de sécurité. Un fichier contenant les mails d'un utilisateur ne devrait être lisisble que par son propriétaire, mais un logiciel de messagerie a la possibilité de changer ses propriétés et les rendre lisibles par tout le monde.
- Les processus héritent des droits des utilisateurs qui les exécutent : Firefox par exemple, s'il est compromis par un trojan, serait en mesure de lire la clé privée de l'utilisateur alors qu'il n'a aucune raison de le faire.
Dans le modèle DAC traditionnel, il existe essentiellement deux niveaux de privilèges, celui de l'utilisateur et celui de l'administrateur root, et il n'y a pas de moyen simple d'appliquer un modèle de moindre privilège. De nombreux processus lancés par root perdent ensuite leurs droits d'être exécutés en tant qu'utilisateur restreint et certains processus peuvent être exécutés dans un 'chroot', mais toutes ces méthodes de sécurité sont discrétionnaires et pas toujours réaliseables.
