|
[ << ] [ < ] [ Sommaire ] [ > ] [ >> ] 1. Présentation de SELinuxTable des matières :
Un type SELinux est un attribut de sécurité assigné à un objet (un fichier, un port réseau, etc.). Le type d'un processus est communément appelé son domaine. Une politique de sécurité SELinux est principalement constituée de règles pour respecter les types, qui décrivent de quelles manières les domaines sont autorisés à interagir avec les objets et avec les autres domaines. Un type est généralement suffixé par « _t », par exemple : sysadm_t. Le type est l'attribut le plus important pour un processus ou un objet, car la plupart des décisions politiques se basent sur les types sources et cibles. La sécurité fournie par SELinux tourne autour des types. Les rôles SELinux sont donc différents de ce que l'on peut trouver dans un système de contrôle d'accès basé sur les rôles (RBAC). Les différentes autorisations ne sont pas attribuées aux rôles. Un rôle décrit l'ensemble des types dont un utilisateur peut se servir. Par exemple, un administrateur qui utilise un système pour exécuter des tâches d'utilisateur classique devrait être dans le rôle staff_r. S'il veut procéder à une tâche d'administration système, il doit alors explicitement basculer dans le rôle sysadm_r. En termes SELinux, la liste des domaines dans lesquels un utilisateur peut se trouver dépend de son rôle. Si un rôle n'est pas autorisé à avoir un certain domaine, une transition vers ce domaine sera rejetée, même si la règle du type permet la transition de domaine. Un rôle est généralement suffixé par un « _r », par exemple : system_r. Qu'est-ce qu'une identité SELinux ? Une identité SELinux est similaire à un nom d'utilisateur Linux. Le changement d'identité devrait être limité à certains cas spécifiques, car le contrôle d'accès basé sur les rôles se repose sur l'identité SELinux. Donc, en général, l'identité SELinux d'un utilisateur ne changera pas tout au long de sa session. L'identifiant utilisateur de Linux peut être changé par set(e)uid, ce n'est donc pas un identifiant approprié pour une identité SELinux. Si on attribue une identité SELinux à un utilisateur, celle-ci doit correspondre au nom d'utilisateur Linux. À chaque identité SELinux on attribue un ensemble de rôles. Configurer la correspondance des identités SELinux Une politique SELinux contient plusieurs identités SELinux génériques qui devraient convenir pour tous les utilisateurs. Cette correspondance n'a besoin d'être configurée que lors d'une utilisation de la politique stricte. Vous n'avez pas besoin de la configurer avec la politique ciblée, car l'identité par défaut (user_u) est suffisante dans tous les cas. Lorsqu'un utilisateur se connecte, l'identité SELinux est déterminée selon cette correspondance.
Pour savoir comment utiliser semanage afin de configurer vos correspondances, lisez notre Guide pratique SELinux. L'utilisation des trois modèles de sécurité précédents ensemble s'appelle un contexte SELinux et se note sous la forme : identité:rôle:type. Le contexte SELinux est la valeur la plus importante dans la décision d'un accès. Un ls -Z typique peut renvoyer un résultat semblable à celui-ci :
Les trois premières colonnes décrivent les permissions, le nom d'utilisateur et le nom de groupe, valeurs typiques de Linux. La quatrième colonne est le contexte du fichier ou du répertoire. On donne le rôle générique object_r aux objets. Des deux autres champs du contexte, on en déduit que les fichiers ont l'identité système et qu'ils sont de types différents, bin_t, boot_t, device_t, et etc_t. Un ps ax -Z typique peut renvoyer ce genre de résultat :
Dans cet exemple, le contexte de chaque processus est affiché en plus des informations typiques. Si on examine cette liste, on remarque que tous les processus du noyau et les démons tournent sous l'identité system_u et avec le rôle system_r. Les domaines individuels dépendent du programme. On note plusieurs utilisateurs connectés en SSH, sous l'identité générique user_u. Enfin, un utilisateur, portant l'identité pebenito, est connecté avec le rôle staff_r et se trouve dans le domaine staff_t. 1.e. Les fichiers de politiques de SELinux Les fichiers sources des politiques de SELinux ne sont plus installés sur le système. Dans les répertoires /usr/share/selinux/{strict,targeted}, vous trouverez une série de paquets de politiques et d'en-têtes afin de construire des modules locaux. Les fichiers de politiques sont traités par m4, puis le compilateur de politique checkmodule vérifie qu'il n'y ait pas d'erreur de syntaxe avant de créer un module de politique. Ensuite, un paquet de politique est créé avec la commande semodule_package en utilisant le module de politique et les contextes de fichiers du module. La politique, une fois empaquetée, peut alors être chargée dans un noyau SELinux en l'insérant dans le magasin de modules. Les paquets de politiques pour cette politique. Ils doivent être insérés dans le magasin de modules afin d'être chargés dans la politique. Dans le paquet, se trouve un module de politique chargeable et éventuellement un fichier de contexte de fichier. Les en-têtes de politiques pour cette politique. 1.f. Les versions de politiques binaires Lors d'une compilation de politique, le fichier binaire résultant contient un numéro de version. La première version qui a été introduite dans le noyau Linux a été la version 15. Le numéro de version n'est en général incrémenté que lorsqu'une nouvelle fonctionnalité ajoutée nécessite des changements de structure de la politique compilée binaire. Par exemple, dans Linux 2.6.5, des extensions concernant les politiques conditionnelles ont été ajoutées. Le numéro de version des politiques résultantes a été incrémenté à 16. Quelle est la version de politique de mon noyau ? La version de politique d'un noyau peut se déterminer à l'aide des outils sestatus ou policyvers. Les noyaux actuels peuvent charger une politique d'une version antécédente, par exemple un noyau en version 17 peut aussi charger les politiques en version 16. Cependant, cette compatibilité pourra être supprimée à l'avenir.
La table suivante indique l'historique des versions de politiques selon la version de Linux 2.6.
1.g. Les extensions de politique conditionnelle Les extensions de politique conditionnelle permettent l'activation et la désactivation de règles à la volée, sans besoin de recharger une politique modifiée. En utilisant les booléens et les expressions de politique, les règles peuvent être appliquées conditionnellement. Afficher les valeurs des booléens L'état des booléens de la politique courante peut être déterminé de deux façons. Premièrement, en utilisant sestatus :
La deuxième méthode est l'utilisation de getsebool, un outil simple qui affiche l'état courant et l'état en attente (pending) des booléens.
La valeur d'un booléen peut être inversée en utilisant la commande togglesebool. On peut spécifier plusieurs booléens sur la ligne de commande. La nouvelle valeur des booléens sera affichée en retour.
La valeur d'un booléen peut également être définie explicitement avec setsebool.
Pour définir la valeur d'un booléen et en faire sa valeur par défaut, utilisez l'option -P.
1.h. Les messages du noyau concernant la politique Lorsque le système tourne, un programme ou un utilisateur peut tenter de faire quelque chose qui viole la politique de sécurité. Si le système respecte la politique (mode enforcing), l'accès sera refusé et un message sera envoyé dans le journal du noyau. Si le système est en mode permissive, l'accès sera autorisé mais il y aura tout de même un message envoyé au journal du noyau. La plupart des messages du noyau provenant de SELinux viennent du cache de vecteurs d'accès (AVC pour Access Vector Cache). Comprendre les refus d'accès est important pour déterminer si une attaque est en cours ou bien si le programme demande un accès non prévu. Voici un exemple de refus d'accès :
Bien que la plupart des messages de l'AVC soient des refus d'accès, il peut aussi de temps en temps y avoir des messages d'audit à propos d'accès autorisés :
Dans ce cas-ci, la demande de charger la politique a été autorisée. C'est un évènement de sécurité critique et est donc toujours audité. Un autre évènement toujours audité est le passage du mode enforcing vers permissive et inversement. SELinux n'enregistrera pas les refus d'accès dans le journal s'il y en a trop à la fois. Cela ne veut pas forcément dire qu'une attaque est en cours. Un programme peut par exemple être en train d'exécuter un stat() sur les fichiers présents dans /dev/. SELinux limite le nombre de messages afin de minimiser les risques de saturation du journal :
Si le comportement du programme est normal et que ces accès doivent bien être refusés, la politique doit alors être modifiée afin de ne pas auditer ces accès.
Cela signifie que le fichier se trouvant sur /dev/hda3 et ayant le numéro d'inode 517610 a le contexte system_u:object_r:bar_t, qui est invalide. Les objets qui ont un contexte invalide sont traités comme s'ils avaient le contexte system_u:object_r:unlabeled_t. 1.i. Autopsie d'un refus d'accès Les refus d'accès contiennent une quantité variable d'information, selon le type d'accès.
Les refus d'accès concernent généralement l'accès à un fichier. Pour mieux comprendre, décortiquons ici le premier message :
Tous les messages de l'AVC n'ont pas forcément tous ces champs, comme notamment les deux exemples suivants. Les champs présents varient en fonction de la classe de l'objet cible. Cependant, les champs les plus importants (le type d'accès, les contextes source et cible et l'objet cible) seront toujours affichés dans un message de l'AVC. Les messages de refus d'accès sont parfois trompeurs car ils peuvent être envoyés pour plusieurs raisons. Pour comprendre ce qu'il se passe, il faut connaitre le comportement du programme et savoir correctement interpréter les messages de refus d'accès. La cible n'est pas forcément un fichier, mais peut aussi être une socket réseau, une communication interprocessus, etc. Dans l'exemple précédent, agetty se voit refuser le droit de poser un verrou sur un fichier. Le type du fichier est var_log_t, ce qui implique que le fichier cible se trouve dans /var/log/. Grâce aux informations supplémentaires fournies par le champ path= du message de refus d'accès, on confirme que le fichier est /var/log/wtmp. Si l'information du chemin complet n'avait pas été disponible, on aurait pu trouver le fichier avec le numéro d'inode. wtmp est un fichier qui contient des informations à propos des utilisateurs actuellement connectés au système et agetty gère justement les connexions depuis un tty. On peut donc en conclure que c'est un comportement normal de la part d'agetty de vouloir mettre à jour wtmp. Cependant, pourquoi cet accès est-il refusé ? Y aurait-il une anomalie dans la politique qui empêcherait agetty de mettre à jour wtmp ? En réalité, c'est wtmp qui a un mauvais contexte. Cela devrait être system_u:object_r:wtmp_t et non pas system_u:object_r:var_log_t. Si cette demande d'accès n'avait pas été bien comprise, l'administrateur aurait pu faire l'erreur d'autoriser les accès en lecture/écriture de getty_t vers les fichiers var_log_t, ce qui aurait été incorrect, puisqu'agetty n'a besoin que de modifier /var/log/wtmp. Cet exemple souligne à quel point il est important de garder les contextes des fichiers dans un état cohérent. Le site de SELinux et le fichier README de SELinux. [ << ] [ < ] [ Sommaire ] [ > ] [ >> ] Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5. |
|