Manuel Gentoo SELinuxTable des matières :
A. Installer Gentoo SELinux1. Installation de Gentoo SELinux1.a. Installation de Gentoo SELinux
La procédure d'installation d'un système Gentoo SELinux est identique à celle d'un système Gentoo normal. Suivez simplement les instructions décrites dans le Manuel Gentoo en tenant compte des remarques qui suivent. Le système sera par la suite converti en SELinux grâce au Guide de conversion vers SELinux. 1.b. Remarques concernant l'installation Seuls ext2, ext3, JFS et XFS sont supportés pour le moment. Les utilisateurs de XFS doivent utiliser des inodes de 512 octets plutôt que la taille par défaut de 256 octets. SELinux utilise les attributs étendus pour stocker les étiquettes de sécurité des fichiers, mais, comme XFS les place dans l'inode, si l'inode est trop petit, un bloc supplémentaire sera utilisé rien que pour stocker les étiquettes, ce qui gaspillera beaucoup d'espace disque et ralentira le système à cause des opérations supplémentaires pour chaque fichier.
Vous pouvez regarder de suite la partie de ce guide qui concerne les options à activer pour avoir SELinux, afin de ne pas recompiler plusieurs fois votre noyau inutilement. B. Conversion vers Gentoo SELinux1. Préliminaires
Tout d'abord, basculez vers le profil SELinux de votre architecture :
1.b. Mise à jour des en-têtes du noyau Nous allons commencer par mettre à jour les paquets essentiels. Tout d'abord, vérifiez la version des en-têtes du noyau qui sont installés.
Si la version des en-têtes est inférieure à 2.4.20, vous devrez les mettre à jour.
Si vous venez de mettre à jour les en-têtes du noyau ou bien si vous n'êtes pas sûr que votre Glibc ait été compilée avec des en-têtes suffisamment récents, vous devez absolument la mettre à jour.
2. Démarrer un noyau SELinux2.a. Installer un noyau SELinux Il est temps d'installer un noyau contenant SELinux. Un noyau 2.6 est requis, nous vous recommandons le paquet hardened-sources.
2.b. Compiler le noyau avec options SELinux Le noyau doit être compilé avec le support des modules de sécurité, de SELinux, de devpts et des étiquettes de sécurité des attributs étendus des systèmes de fichiers. Référez-vous au guide principal d'installation pour les autres options du noyau.
Les étiquettes de sécurité des attributs étendus doivent être activées pour devpts et pour tous vos types de systèmes de fichiers. Devfs n'est pas utilisable avec SELinux et doit donc être désactivé. Certaines options n'existent pas dans les noyaux 2.6 plus vieux, telles que le support de l'audit ou « runtime disable ». Dans les noyaux plus récents, le support des attributs étendus pour proc et tmps sont activés par défaut et l'option n'apparait pas dans le menuconfig.
Maintenant, compilez et installez votre noyau et ses modules. Ne redémarrez pas encore le système. SELinuxFS doit également être monté au démarrage. Ajoutez cette ligne à votre /etc/fstab :
SELinux ne supporte pas Devfs. Vous devez configurer Baselayout afin qu'il utilise soit une arborescence statique de fichiers de périphériques, soit udev. Si vous souhaitez utiliser udev, l'archivage des fichiers périphériques doit être désactivé. Éditez le fichier /etc/conf.d/rc. Mettez RC_DEVICES à static ou udev et RC_DEVICE_TARBALL à no. Si vous avez des fichiers de périphériques personnalisés, static est suggéré, sinon udev.
Nous devons créer quelques répertoires avant de redémarrer.
Maintenant, redémarrez. 3. Installer les outils SELinux3.a. Installer les paquets SELinux Installez les bibliothèques, les utilitaires et les politiques de base. La version des politiques peut éventuellement être ajustée, référez-vous à la vue d'ensemble de SELinux pour plus d'informations sur les versions des politiques. Enfin, chargez les politiques.
3.b. Choisir le type de politique Depuis la version 2006.1, les utilisateurs ont maintenant la possibilité de choisir entre une politique stricte ou une politique ciblée. Avec la politique stricte, tous les processus sont confinés. Si vous êtes familier avec la politique Gentoo SELinux datant d'avant 2006.1, cette politique était stricte. La politique stricte est suggérée pour les serveurs. Gentoo ne supporte pas la politique stricte sur un système de bureau. La politique ciblée est différente, seuls les processus avec un accès au réseau sont confinés. Gentoo ne supporte les stations de travail qu'avec la politique ciblée. Cette politique peut aussi être utilisée sur des serveurs. Éditez le fichier /etc/selinux/config pour définir le type de politique.
3.e. Installer des paquets modifiés pour SELinux Plusieurs paquets systèmes contiennent des modifications pour SELinux. Ces modifications fournissent diverses fonctionnalités supplémentaires pour SELinux, comme par exemple l'affichage du contexte des fichiers.
D'autres paquets disposent de modifications pour SELinux, mais ils sont optionnels. Les paquets suivants doivent être réinstallés s'ils sont déjà présents sur le système, afin que les modifications concernant SELinux soient appliquées :
3.d. Installer les politiques de sécurité applicatives À l'avenir, lorsque vous installerez un paquet, la politique de sécurité correspondante sera installée avant, en tant que dépendance. Mais pour le moment, dans notre processus de conversion du système, il nous reste à installer les politiques applicatives des paquets que l'on a déjà installés. Selinux-base-policy comprend déjà les politiques de la majorité des paquets du profil system. Regardez dans le répertoire /usr/portage/sec-policy, chaque entrée correspond à une politique. La convention de nommage est selinux-NOMPAQUET, où NOMPAQUET est le nom du paquet auquel est associée la politique de sécurité. Par exemple, le paquet selinux-apache est le paquet qui contient la politique de sécurité SELinux pour le paquet net-www/apache. Installez chacune des politiques désirées et chargez-les. Si vous installez une station de travail, n'oubliez pas le paquet selinux-desktop.
3.e. Étiqueter les systèmes de fichiers Maintenant, étiquetez les systèmes de fichiers. Cela assigne une étiquette de sécurité à chaque fichier contenu dans le système de fichiers. Il est important de garder ces étiquettes dans un état cohérent.
Redémarrez, connectez-vous, puis ré-étiquetez tous les fichiers encore une fois pour vous assurez que tous les fichiers sont étiquetés (certains fichiers ont pu être créés pendant l'arrêt et le redémarrage du système).
SELinux est maintenant installé ! C. Utiliser SELinux1. Présentation de SELinuxUn 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. 2. Guide SELinux2.a. Charger une politique dans un noyau SELinux Vous devez vous placer dans le rôle sysadm_r.
Votre utilisateur doit avoir accès au rôle cible. Dans cet exemple, nous nous mettons dans le rôle sysadm_r.
2.c. Spécifier les rôles disponibles pour un utilisateur Il y a une correspondance entre les utilisateurs Linux et les identités SELinux. La politique dispose d'utilisateurs SELinux génériques selon les configurations des rôles. Par exemple, pour associer l'utilisateur pebenito à l'identité SELinux staff_u :
La politique n'a pas besoin d'être rechargée. Si l'utilisateur est connecté, il doit simplement se reconnecter afin que les changements soient pris en compte. 2.d. Ré-étiqueter les systèmes de fichiers Vous devez vous placer dans le rôle sysadm_r.
2.e. Ré-étiqueter un paquet individuel En plus de pouvoir ré-étiqueter des systèmes de fichiers entiers, vous pouvez aussi ré-étiqueter des paquets de Portage individuellement. Pour cela, vous devez vous placer dans le rôle sysadm_r.
On utilise le script rlpkg avec un nombre quelconque de noms de paquets comme arguments. 2.f. Chercher les bibliothèques qui utilisent les relocations de textes SELinux contient des protections améliorées de la mémoire. Une des fonctionnalités supportées et d'autoriser les relocations de textes ELF. Les bibliothèques avec des relocations de textes ont une étiquette spéciale et l'outil rlpkg possède une option pour rechercher ces bibliothèques.
Cela sera également effectué après un ré-étiquetage complet. 2.g. Démarrer les démons dans le bon domaine Contrôler les démons qui possèdent des scripts d'initialisation dans /etc/init.d est très légèrement différent avec SELinux. La commande run_init doit être utilisée pour lancer les scripts, afin de s'assurer qu'ils soient exécutés dans le bon domaine. La commande est identique, excepté qu'elle est préfixé par run_init. Vous devez être dans le rôle sysadm_r.
Intégration de run_init dans Gentoo run_init a été intégré dans le système de scripts d'initialisation de Gentoo. Avec SELinux installé, les services peuvent être démarrés et arrêtés comme d'habitude, sauf que maintenant ils authentifieront l'utilisateur.
2.h. Basculer entre les modes enforcing et permissive Basculer entre les différents modes de SELinux est très simple. Envoyez 1 pour enforcing ou 0 pour permissive au fichier /selinux/enforce pour définir le mode. En lisant le contenu du fichier, vous obtiendrez le mode courant. Si l'option du noyau « NSA SELinux Development Support » est désactivée, le système sera toujours en mode enforcing et ne pourra pas être passé en mode permissive.
Une machine dont le support du développement a été activé dans le noyau peut être démarrée en mode enforcing en spécifiant l'option enforcing=1 sur la ligne de commande de démarrage du noyau dans le chargeur de démarrage (Grub, LILO, etc.). En sus des options du noyau mentionnées précédemment, le mode de démarrage peut être défini dans le fichier /etc/selinux/config.
Le réglage défini dans ce fichier sera écrasé par la valeur donnée en argument du noyau décrite précédemment. 2.i. Comprendre le retour de la commande sestatus L'outil sestatus nous permet de récupérer des informations détaillées à propos des spécificités de SELinux. L'option -v nous fournit des détails supplémentaires à propos des contextes des processus et des fichiers. Le résultat de la commande est divisé en quatre sections. Sestatus ne donne des informations complètes qu'à un utilisateur connecté en root ou bien se trouvant dans le rôle sysadm_r.
Les informations principales du rapport sont fournies dans la première section. La première ligne montre si les fonctions du noyau SELinux existent et sont activées. Si le statut est désactivé (disabled), soit le noyau n'a pas le support SELinux, soit la politique n'est pas chargée. La seconde ligne montre le point de montage du système de fichiers SELinux. Lors d'une utilisation normale, ce sera /selinux. La troisième ligne montre le mode SELinux courant, soit enforcing, soit permissive. La quatrième ligne montre la version de la base de données de la politique supportée par le noyau actuel.
La seconde section affiche l'état des booléens concernant la politique. La colonne de gauche contient le nom du booléen et celle de droite son état : active ou inactive. Cette section n'existe pas avec les noyaux en version 15.
La troisième section affiche les contextes des processus courants ainsi que de quelques processus importants. Si un processus est exécuté dans un contexte incorrect, il ne fonctionnera pas correctement.
La quatrième section affiche les contextes du terminal contrôlant le processus courant ainsi que de quelques fichiers importants. Pour les liens symboliques, le contexte du lien ainsi que celui de la cible de celui-ci sont affichés. Si un fichier a un contexte incorrect, le fichier peut être inaccessible ou posséder des permissions incorrectes par rapport à un processus en particulier. 3. Foire aux Questions sur SELinuxEst-ce que SELinux permet de limiter les ressources systèmes ? Non, la limitation de ressource n'est pas dans le domaine d'un système de contrôle d'accès. Si vous cherchez ce type de fonctionnalités, orientez-vous plutôt vers GRSecurity et RSBAC. 3.b. SELinux et les autres projets Hardened Puis-je utiliser SELinux et GRSecurity (et PaX) ? Oui, SELinux peut être utilisé avec GRSecurity et/ou PaX sans problème. Par contre, nous vous suggérons de ne pas utiliser GRACL puisqu'il serait redondant avec le contrôle d'accès de SELinux. Puis-je utiliser SELinux avec le compilateur Hardened (PIE-SSP) ? Oui. De plus, nous vous recommandons d'utiliser PaX pour tirer profit au maximum des fonctionnalités PIE du compilateur. Puis-je utiliser SELinux avec RSBAC ? Aucune idée. Tenez-nous au courant si vous essayez... 3.c. SELinux et les systèmes de fichiers Puis-je utiliser SELinux sur mon système de fichiers ? SELinux est utilisable sur de l'ext2, ext3, JFS et XFS. Reiserfs (reiser3) dispose des attributs étendus mais l'implémentation n'a jamais été terminée et ne fonctionne plus depuis 2.6.14. Reiser4 n'est pas supporté. Et sur les autres systèmes de fichiers ? SELinux peut également monter les systèmes de fichiers annexes, tels que vfat et iso9660, mais avec une grosse restriction : tous les fichiers du montage auront le même type SELinux, puisque le système de fichiers ne supporte pas les attributs étendus. Tmpfs est le seul système de fichiers annexe à supporter les attributs étendus. Puis-je utiliser SELinux sur un montage réseau ? Oui, SELinux peut monter les systèmes de fichiers en réseau, tels que NFS et CIFS, mais avec la même restriction : tous les fichiers du montage auront le même type SELinux, puisque le système de fichiers ne supporte pas les attributs étendus. Espérons que les systèmes de fichiers en réseau pourront gérer les attributs étendus dans un avenir proche. 3.d. Messages d'erreur de Portage emerge se plaint de ne pas trouver un module SELinux
Ce message indique que le module SELinux pour Portage est manquant ou endommagé. Ce peut aussi être Python qui a été mis à jour vers une nouvelle version, ce qui nécessite la recompilation de python-selinux. Réinstallez dev-python/python-selinux. Si des paquets ont été installés avec cette erreur, ils doivent être ré-étiquetés une fois que le problème est résolu. En cas de doute sur les paquets à ré-étiqueter, ré-étiquetez tout. 3.e. Messages d'erreur du noyau à propos de SELinux Lors du démarrage, j'obtiens une erreur register_security
Cela signifie que le module Capability LSM n'a pas pu s'enregistrer en tant que module principal, puisque SELinux l'est déjà. Le troisième message signifie qu'il s'est enregistré avec SELinux comme un module secondaire. C'est normal. 3.f. Messages d'erreur de setfiles Le ré-étiquetage échoue à cause d'un contexte invalide
Commencez par vérifier que /selinux soit bien monté, car sinon setfiles ne peut pas valider de contexte et croira que tous les contextes sont invalides. Si /selinux est monté, alors il est probable qu'une nouvelle politique n'ait pas encore été chargée et donc les contextes ne soient pas encore valides. 4. L'infrastructure de gestion de SELinux4.a. L'infrastruction de gestion de SELinux L'infrastructure de gestion de SELinux s'occupe de plusieurs aspects des politiques SELinux. Ces outils de gestion sont basés sur la bibliothèque centrale libsemanage. Plusieurs programmes de gestion permettent d'achever plusieurs tâches, dont notamment semanage et semodule. Ils vous permettront de configurer certains aspects sans avoir besoin de la source de la politique. 4.b. Gestion des modules de politiques SELinux Qu'est-ce qu'un module de politique ? SELinux gère les politiques modulaires. Cela consiste en plusieurs morceaux de politiques qui sont assemblés pour former une politique à charger dans le noyau. La structure est assez similaire au noyau lui-même et à ses modules : une image principale du noyau est chargée, puis plusieurs modules du noyau peuvent être ajoutés (à condition que leurs dépendances soient satisfaites) et supprimés, à chaud, sans redémarrer le système. De même, chaque politique est constituée d'un module de base et d'un nombre éventuellement nul de modules de politiques qui forment la politique. Les modules sont construits en compilant un morceau de politique et en créant un paquet de politique (*.pp) contenant la politique compilée et éventuellement des contextes de fichiers. Le paquet du module de base (base.pp) contient le strict nécessaire de la politique. Toutes les politiques modulaires doivent au moins avoir leur module de base. Dans Gentoo, nous avons rajouté dans ce paquet des politiques pour toutes les parties du profil système. Il est installé par l'ebuild selinux-base-policy. Les autres ebuilds dans Portage contiennent un ou plusieurs modules de politiques. Pour plus d'informations à propos de l'écriture d'un module de politique, en particulier pour pouvoir personnaliser une politique, veuillez consulter le guide des modules de politiques. Lorsqu'un module de politique est inséré ou supprimé, les modules sont copiés depuis ou supprimé du magasin de modules. Ce dépôt contient une copie des modules qui ont été utilisés pour créer la politique courante, ainsi que plusieurs fichiers annexes. Ce dépôt se trouve dans /etc/selinux/{strict,targeted}/modules. Vous ne devrez jamais avoir besoin d'accéder à ces fichiers directement. Un outil basé sur libsemanage devrait s'en occuper pour vous. Libsemanage manipule le magasin de modules à l'aide de transaction. Cela signifie que si un ensemble d'opérations (une transaction) sont exécutées sur le magasin et qu'une partie échoue, alors la transaction entière est annulée. Cela empêche le magasin de se retrouver dans un état incohérent. La gestion du magasin de modules passe par la commande semodule. L'option -l permet d'en lister son contenu.
Puisque le module de base est requis dans tous les cas et qu'il n'a pas de version, il n'est pas affiché dans la liste. Tous les autres modules sont affichés avec leur version. Ajouter un module de politique Le module est référencé par son nom.
Cela insérera le module dans le magasin de la politique actuellement configurée, comme spécifié dans /etc/selinux/config. Si l'insertion réussit, la politique sera chargée, sauf si l'option -n est spécifiée. Pour charger le module dans un autre magasin de modules, utilisez l'option -s.
Puisque nous spécifions un autre magasin, la politique ne sera pas chargée. Retirer un module de politique Le module est référencé par son nom dans le magasin de modules.
Cela supprimera le module du magasin de la politique courante, spécifiée dans /etc/selinux/config. Si la suppression a marché, la politique sera rechargée, sauf si l'option -n a été spécifiée. L'option -s fonctionne également pour une suppression de module. 4.c. Configurer les associations d'identifiants d'utilisateurs La méthode actuelle pour assigner des ensembles de rôles à un utilisateur est de mettre en place une liste d'associations entre les utilisateurs Linux et les identités SELinux. Lorsqu'un utilisateur se connecte, le programme login utilisera cette liste pour associer la bonne identité SELinux à l'utilisateur. S'il n'y a pas d'association pour un utilisateur, on utilise l'entrée __default__. La gestion des associations entre utilisateurs Linux et identités SELinux est réalisée par semanage.
Pour faire correspondre l'utilisateur pebenito à l'identité staff_u :
La vue d'ensemble de SELinux contient une description des identités disponibles. Pour supprimer l'association de l'utilisateur pebenito :
4.d. Configurer les valeurs par défaut des booléens Le programme setsebool est maintenant un outil utilisant libsemanage. La fonction de base de cet outil est d'assigner une valeur à un booléen. Pourtant, si la machine est redémarrée, les booléens seront tous réinitialisés à la valeur spécifiée dans la politique. Pour configurer une valeur tout en demandant qu'elle soit par défaut dans la politique, utilisez l'option -P.
La commande précédente définit la valeur du booléen fcron_crond à 1 et définit également cette valeur comme étant celle par défaut. 4.e. Configurer les identités de SELinux En principe, on n'a pas besoin d'ajouter des identités de SELinux à la politique de sécurité, car les associations identité/login suffisent. Une bonne raison d'ajouter une nouvelle identité serait pour améliorer les audits, car l'identité SELinux apparait directement dans le contexte du message de refus d'accès. La gestion des identités SELinux est assurée par l'outil semanage.
En plus de lister les rôles de l'identité, il faut spécifier un préfixe. Ce préfixe doit correspondre à un rôle, par exemple staff ou sysadm, et est utilisé pour étiqueter les répertoires racines des utilisateurs. Si le préfixe utilisé est staff, les utilisateurs Linux qui seront associés à cette identité auront leur répertoire racine étiqueté staff_home_dir_t. Pour ajouter l'identité test_u contenant les rôles staff_r et sysadm_r avec le préfixe staff :
Supprimer une identité SELinux Pour supprimer l'identité SELinux test_u :
5. Les modules de politique localeCe guide explique comment mettre en place un module de politique permettant l'ajout de règles locales à la politique. Copiez l'exemple de Makefile depuis le répertoire doc de selinux-base-policy vers le répertoire qui sera utilisé pour la construction de la politique. Il est suggéré d'utiliser /root/. Les endroits dans lesquels semodule peut lire les modules de politique comprennent les répertoires utilisateurs des sysadm.
La plupart des déclarations sont utilisables dans un module, ainsi que quelques déclarations supplémentaires.
En plus des règles de base, quelques déclarations sont requises par les modules de politiques. La première est une macro policy_module() qui contient le nom du module et sa version. Le bloc require suivant spécifie tous les types qui sont requis afin que le module puisse fonctionner. Tous les types utilisés dans un module doivent soit être déclarés dans ce module, soit requis par ce module. 5.d. Écrire un fichier FC (facultatif) Le fichier de contextes est facultatif et utilise la même syntaxe que d'habitude.
Les types utilisés dans ce fichier de contexte doivent être requis ou déclarés dans le fichier TE. 5.h. Compiler les modules de politique Lancez simplement make pour construire tous les modules du répertoire. Chaque module sera compilé pour fonctionner avec la politique courante, comme spécifié dans /etc/selinux/config.
Pour construire un module pour une politique différente que celle en place, utilisez l'option NAME=.
Les modules peuvent être chargés dans la politique courante simplement en utilisant la cible load du Makefile.
La cible load respecte également l'option NAME=. Accessoirement, la commande semodule peut être aussi utilisée pour charger des modules individuellement.
5.g. Faire un module avec la SELinux Reference Policy La nouvelle politique de Gentoo est basée sur la SELinux Reference Policy. Pour plus d'information à propos de la construction d'un module selon SELinux Reference Policy, consultez le wiki Reference Policy. 6. Références sur SELinux
D. Résolution des problèmes liés à SELinux1. La politique n'est pas chargée au démarrage6.a. Vérifier la disponibilité de la politique Vous devez être dans sysadm_r pour effectuer cette action. Une politique binaire doit être disponible dans /etc/selinux/{strict,targeted}/policy. Si ce n'est pas le cas, installez la politique.
1.b. Vérifier qu'init peut charger la politique La dernière vérification consiste à s'assurer qu'init puisse charger la politique. Exécutez ldd sur /sbin/init et, si libselinux ne fait pas partie des bibliothèques listées, réinstallez sysvinit.
Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger la politique. 2. Problème de connexion localeVous devez être dans sysadm_r pour effectuer ces actions. Lancez sestatus -v et cliquez sur le premier contexte qui ne correspond pas :
2.b. Le contexte d'init est incorrect Plusieurs raisons peuvent être à l'origine d'un mauvais contexte pour init. Tout d'abord, vérifiez qu'init est correctement étiqueté en vous référant au résultat de sestatus concernant /sbin/init. Si ce n'est pas system_u:object_r:init_exec_t, ré-étiquetez sysvinit.
Vérifier la disponibilité de la politique Vous devez être dans sysadm_r pour effectuer cette action. Une politique binaire doit être disponible dans /etc/selinux/{strict,targeted}/policy. Si ce n'est pas le cas, installez la politique.
Vérifier qu'init peut charger la politique La dernière vérification consiste à s'assurer qu'init puisse charger la politique. Exécutez ldd sur /sbin/init et, si libselinux ne fait pas partie des bibliothèques listées, réinstallez sysvinit.
Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger la politique. 2.c. Le contexte d'Agetty est incorrect Vérifier qu'Agetty est étiqueté correctement. Selon la sortie de sestatus concernant /sbin/agetty, si le contexte n'est pas system_u:object_r:getty_exec_t, ré-étiquetez util-linux. Ensuite, redémarrez tous les Agetty.
Tous les Agetty devraient maintenant se trouver dans le contexte system_u:object_r:getty_exec_t. Essayez de vous reconnecter à nouveau. 2.d. Le contexte de Login est incorrect Le programme Login (/bin/login) n'est pas étiqueté correctement. Ré-étiquetez shadow.
Le contexte de /bin/login devrait maintenant être system_u:object_r:login_exec_t. Essayez de vous reconnecter à nouveau. 2.e. Le contexte de PAM est incorrect Sshd doit pouvoir utiliser PAM pour authentifier les utilisateurs. Le programme de PAM qui vérifie le mot de passe (/sbin/unix_chkpwd) doit être étiqueté correctement afin que Sshd puisse transiter vers le contexte de vérification du mot de passe. Ré-étiquetez PAM.
Le contexte du programme de vérification de mot de passe devrait maintenant être system_u:object_r:chkpwd_exec_t. Essayez de vous reconnecter à nouveau. 2.f. Les contextes des fichiers de mots de passes sont incorrects Le fichier passwd (/etc/passwd) et shadow (/etc/shadow) doivent être correctement étiquetés sinon PAM ne pourra pas authentifier les utilisateurs. Ré-étiquetez les fichiers.
Leur contexte devraient maintenant être respectivement system_u:object_r:etc_t et system_u:object_r:shadow_t. Essayez de vous reconnecter à nouveau. 2.g. Le contexte de Bash est incorrect Bash doit être correctement étiqueté afin que l'utilisateur puisse transiter vers son domaine lors de la connexion. Ré-étiquetez bash.
Bash (/bin/bash) doit maintenant avoir le contexte system_u:object_r:shell_exec_t. Essayez de vous reconnecter à nouveau. 3. Problème de connexion distanteVous devez être dans sysadm_r pour effectuer ces actions. Lancez sestatus -v et cliquez sur le premier contexte qui ne correspond pas :
3.b. Le contexte d'init est incorrect Plusieurs raisons peuvent être à l'origine d'un mauvais contexte pour init. Tout d'abord, vérifiez qu'init est correctement étiqueté en vous référant au résultat de sestatus concernant /sbin/init. Si ce n'est pas system_u:object_r:init_exec_t, ré-étiquetez sysvinit.
Vérifier la disponibilité de la politique Vous devez être dans sysadm_r pour effectuer cette action. Une politique binaire doit être disponible dans /etc/selinux/{strict,targeted}/policy. Si ce n'est pas le cas, installez la politique.
Vérifier qu'init peut charger la politique La dernière vérification consiste à s'assurer qu'init puisse charger la politique. Exécutez ldd sur /sbin/init et, si libselinux ne fait pas partie des bibliothèques listées, réinstallez sysvinit.
Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger la politique. 3.c. Le contexte de Sshd est incorrect Une autre possibilité est que sshd ne soit pas étiqueté correctement et qu'il ne tourne donc pas dans le bon domaine. Ré-étiquetez openssh, puis relancez sshd.
3.d. Le contexte de PAM est incorrect Sshd doit pouvoir utiliser PAM pour authentifier les utilisateurs. Le programme de PAM qui vérifie le mot de passe (/sbin/unix_chkpwd) doit être étiqueté correctement afin que Sshd puisse transiter vers le contexte de vérification du mot de passe. Ré-étiquetez PAM.
Le contexte du programme de vérification de mot de passe devrait maintenant être system_u:object_r:chkpwd_exec_t. Essayez de vous reconnecter à nouveau. 3.e. Les contextes des fichiers de mots de passes sont incorrects Le fichier passwd (/etc/passwd) et shadow (/etc/shadow) doivent être correctement étiquetés sinon PAM ne pourra pas authentifier les utilisateurs. Ré-étiquetez les fichiers.
Leur contexte devraient maintenant être respectivement system_u:object_r:etc_t et system_u:object_r:shadow_t. Essayez de vous reconnecter à nouveau. 3.f. Le contexte de Bash est incorrect Bash doit être correctement étiqueté afin que l'utilisateur puisse transiter vers son domaine lors de la connexion. Ré-étiquetez bash.
Bash (/bin/bash) doit maintenant avoir le contexte system_u:object_r:shell_exec_t. Essayez de vous reconnecter à nouveau. 3.g. Autres problèmes avec sshd Premièrement, assurez-vous que le shell de l'utilisateur est valide.
Si la commande précédente ne renvoie rien ou renvoie un shell incorrect, redéfinissez le shell de cet utilisateur.
PAM doit être activé dans sshd. Vérifiez que cette ligne soit bien décommentée dans le fichier /etc/ssh/sshd_config :
SELinux ne permet actuellement qu'à PAM et à quelques rares autres programmes d'accéder directement au fichier /etc/shadow. Openssh doit donc utiliser PAM pour la vérification des mots de passes (cela ne concerne donc pas l'accès par clé publique). Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5. |
|