DOCS/UNIX/SElinux : Différence entre versions
Ligne 96 : | Ligne 96 : | ||
{{NOTE| | {{NOTE| | ||
− | contenu=l'option -Z utilisée dans la commande <code>ls</code> fonctionnera avec la majorité des commandes afin de montreer le contexte de sécurité SELinux de la ressource (ex : 'ls -Z', 'ps auX', id -Z etc ... | + | contenu=l'option '''-Z''' utilisée dans la commande <code>ls</code> fonctionnera avec la majorité des commandes afin de montreer le contexte de sécurité SELinux de la ressource (ex : 'ls -Z', 'ps auX', id -Z etc ... |
}} | }} |
Version du 11 décembre 2020 à 16:30
Sommaire
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 des problèmes 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.
La solution
SELinux suit de beaucoup plus près le modèle des moindre priviléges. Par défaut, dans un cadre d'application stricte, tout est refusé, puis une série de politiques d'exceptions sont rédigées qui donnent à chaque élément du système (un service, un programme ou un utilisateur) uniquement l'accès nécessaire pour fonctionner. Si un service, un programme ou un utilisateur tente par la suite d'accéder ou de modifier un fichier ou une ressource non nécessaire à son fonctionnement, l'accès lui est refusé et l'action est tracée.
Etant donné que SELinux est directement intégré au noyau, les applications n'ont pas besoin d'être spécialement écrites ou modifiées pour fonctionner sous SELinux, bien qu'évidement, si elles sont écrites pour surveiller les codes d'erreurs retournés par SELinux, elles ne pourront que d'autant mieux fonctionner par la suite. Si SELinux bloque une action, cela est signalé à l'application sous-jacente comme une erreur normale (ou, du moins, conventionnelle) de type "accès refusé" à l'application. Cependant, de nombreuses applications ne testent pas tous les codes de retour lors des appels au système et peuvent ne pas renvoyer de message expliquant le problème ou peuvent renvoyer un message trompeur. D'où la réticence de nombreux administrateurs à déployer SELinux sur leurs système.
Les modes de fonctionnement SELinux
SELinux dispose de trois modes de fonctionnement de base, dont le mode Enforcing qui est défini comme mode par défaut à l'installation d'un système. Il existe cependant un qualificatif supplémentaire de targeted ou mls qui contrôle la manière dont les règles SELinux sont appliquées, le niveau targeted étant le moins strict.
- Enforcing : Le mode par défaut qui activera et appliquera la politique de sécurité de SELinux sur le système, en refusant l'accès et en enregistrant les actions
- Permissive : En mode permissif, SELinux est activé mais n'appliquera pas la politique de sécurité, se contentant d'avertir et de consigner les actions. Le mode permissif est utile pour analyser de diagnostiquer les problèmes liés à SELinux
- disabled : SELinux est désactivé
Le mode SELinux peut être consulté et modifié en utilisant l'outil SELinux Management GUI disponible dans le menu Administration ou à partir de la ligne de commande en exécutant "system-config-selinux" (l'outil SELinux Management GUI fait partie du paquet policycoreutils-gui et n'est pas installé par défaut).
Les utilisateurs qui préfèrent la ligne de commande peuvent utiliser la commande sestatus
pour afficher l'état actuel de SELinux :
sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31
La commande setenforce
peut être utilisée pour switcher temporairement entre les modes Enforcing et Permissive à chaud. Mais il est important de noter que ce changement n'est pas persistant à la suite d'un reboot system
Pour rendre persistant le mode de fonctionnement de SELinux, il faut editer le fichier de configuration /etc/selinux/config
en remplaçant la valeur du paramaètre SELINUX= par 'Enforcing', 'Permissive' ou 'Disabled'. Exemple :
SELINUX=Permissive
sans utiliser d'éditeur, la commande perl
suivante peut s'avérer utile :
perl -pi -e 's/SELINUX=.*$/SELINUX=Permissive/g' /etc/selinux/config
la commande équivalente avec sed
sed -i 's/^SELINUX=.*$/SELINUX=permissive/' /etc/selinux/config
|
SELinux Policy
Comme indiqué, SELinux suit le modèle du moindre privilège ; par défaut, tout est refusé et ensuite une politique est rédigée qui donne à chaque élément du système uniquement l'accès nécessaire pour fonctionner. Cette description décrit le mieux la politique stricte. Cependant, il est difficile d'écrire une politique qui convienne à la large gamme de circonstances dans lesquelles un produit tel que Enterprise Linux est susceptible d'être utilisé. Le résultat final est que SELinux est susceptible de causer des problèmes aux administrateurs système et aux utilisateurs finaux et que, plutôt que de résoudre ces problèmes, les administrateurs système peuvent simplement désactiver SELinux, ce qui met en échec les protections intégrées.
De par sa conception, SELinux permet d'écrire différentes politiques qui sont interchangeables. La politique par défaut dans Redhat/CentOS est la politique Targeted qui "cible" et confine les processus système sélectionnés.
Tous les autres processus du système et tous les programmes restants de l'espace utilisateur, ainsi que toutes les applications internes, c'est-à-dire tout le reste du système, fonctionnent dans un domaine non confiné par défaut et ne sont donc pas couverts par le modèle de protection SELinux.
Un objectif pourrait être que chaque processus installé et, par défaut, fonctionnant au démarrage, soit exécuté dans un domaine confiné. La politique ciblée est conçue pour protéger autant de processus clés que possible sans nuire à l'expérience de l'utilisateur final et la plupart des utilisateurs devraient ignorer totalement que SELinux est en cours d'exécution.
SELinux Access Control
La politique Targeted utilisée sous Redhat/Centos dispose de 4 formes de contrôles d'accès :
- Type Enforcement (TE) : principal mécanisme de contrôle d'accès utilisé dans la politique Tergetetd
- Role-Based Access Control (RBAC) : Basé sur les utilisateurs SELinux (pas nécessairement les mêmes que l'utilisateur Linux), mais non utilisé dans la configuration par défaut de la politique Targeted
- Multi-Level Security (MLS): : Peu utilisé et souvent caché dans la politique Targetetd par défaut.
- Multi-Category Security(MCS): : Une extension de la sécurité à plusieurs niveaux, utilisée dans la politique ciblée pour mettre en œuvre le cloisonnement des machines virtuelles et des conteneurs
Tous les processus et fichiers ont un contexte de sécurité SELinux. Voyons cela en action en examinant le contexte de sécurité SELinux de la page d'accueil d'Apache : /var/www/html/index.html
ls -lZ /var/www/html/index.html
-rw-------. 1 apache apache sysadm_u:object_r:httpd_sys_content_t:s0 0 11 déc. 17:25 /var/www/html/index.html
|