Guide Gentoo Grsecurity version 2Le projet grsecurity, hébergé sur le site http://www.grsecurity.org, propose un certain nombre de correctifs pour le noyau Linux pour améliorer la sécurité de l'ensemble de votre système. Dans le chapitre suivant nous présenteront l'ensemble des fonctionnalités apportées par grsecurity. Une liste complète est maintenue à jour sur la page des fonctionnalités de grsecurity. Dans la mesure où la plupart des fonctionnalités apportées par grsecurity sont liées au noyau, une grande partie de ce document présente en détail certaines fonctionnalités du noyau et leurs opérations « sysctl » (dans la mesure du possible). Intégration au projet Gentoo Hardened Le projet Gentoo Hardened maintient les améliorations liées à la sécurité sous Gentoo. Ce qui inclut, mais n'est pas limité à grsecurity. Tout au long de ce document nous allons parler de la configuration du noyau en utilisant des noms de variables comme CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. Ce sont des variables que le noyau utilise lors de la construction pour déterminer quelles fonctionnalités doivent être compilées ou non. Quand vous configurez votre noyau avec la commande make menuconfig (ou similaire) vous disposez d'une interface utilisateur dans laquelle on vous propose de choisir un certain nombre d'options du noyau. Si vous sélectionnez le bouton Help pour une fonctionnalité donnée, vous pourrez voir que les options correspondent en fait à ces mêmes variables du noyau. Vous pouvez donc toujours configurer votre noyau comme vous le souhaitez, en faisant bien sûr attention à ce que vous choisissez. Et si vous n'arrivez pas à trouver une option spécifique, vous pouvez toujours éditer le fichier/usr/src/linux/.config à la main. Évidemment, pour pouvoir choisir parmi les options de noyau grsecurity vous devez activer le support de grsecurity dans votre noyau :
Combattre l'exploitation des bogues logiciels PaX introduit un certain nombre de mécanismes de sécurité qui rendent encore plus difficile l'exploitation de bogues logiciels par les attaquants lorsqu'elles concernent des corruptions de mémoire (ne croyez donc pas que PaX vous protégera contre toutes les attaques possibles de bogues logiciels). Le document d'introduction de PaX parle de trois techniques d'attaque possibles :
Une méthode de prévention est d'interdire aux codes exécutables de se stocker dans une mémoire en écriture. Lors de l'exécution d'un processus, celui-ci aura besoin de cinq zones mémoires différentes :
La première méthode de prévention utilisée par PaX appelée NOEXEC a pour but de permettre le contrôle de la génération du code d'exécution. Elle marque les pages mémoires qui ne contiennent pas de code exécutable comme étant des zones non-exécutables. Cela signifie que le tas et la pile qui ne contiennent que des données et ne devraient pas contenir de code exécutable seront marqués comme non-exécutables. Les attaques qui mettent du code à exécuter dans ces zones avec l'intention de les exécuter échoueront. Pour dire vrai, NOEXEC va plus loin et les lecteurs intéressés devraient lire la documentation de NOEXEC pour PaX. La seconde méthode de prévention employée par PaX s'appelle ASLR (Address Space Layout Randomization, pour Allocation aléatoire de l'espace adressé). Elle rend le processus d'allocation de la mémoire aléatoire pour chaque demande de mémoire. Si auparavant la mémoire était assignée de manière contiguë (ce qui signifie que les exploitations permettent de savoir où sont situées les zones mémoire de chaque tâche), ASLR rend aléatoire cette assignation, ce qui rend inutile l'utilisation de techniques utilisant ce type d'information. Pour plus d'informations sur ASLR lisez la documentation de ASLR pour PaX. Les configurations noyau recommandées pour l'usage de PaX sont :
Si vous utilisez un système non-x86, vous n'aurez pas la variable CONFIG_GRKERNSEC_PAX_NOEXEC. À la place vous devez sélectionner la variable CONFIG_GRKERNSEC_PAX_PAGEEXEC qui est la seule implémentation de méthode de type non-exécution disponible. Toutes les applications ne s'accordent pas bien avec les restrictions de sécurité de PaX. Par exemple, xorg-x11, java, mplayer, xmms n'aiment pas PaX. Si vous voulez pouvoir les utiliser vous pouvez augmenter leur protection en utilisant les paquets chpax et paxctl.
chpax fournit un script d'initialisation qui gère la plupart des configurations d'applications connues pour vous :
pax-utils est une petite boîte à outils qui inclut des applications très pratiques pour administrer un serveur utilisant PaX.
Les outils les plus intéressants sont scanelf et pspax :
Vérifier la configuration de PaX Peter Busser a écrit une suite de tests de régression nommée paxtest. Cet outil vérifiera plusieurs cas de vecteurs d'attaques possibles et vous informera des résultats. Lorsque vous l'exécutez, il laisse un fichier de jounalisation nommé paxtest.log dans le répertoire de travail courant.
Dans l'exemple précédent, vous remarquerez que :
Contrôle d'accès basé sur des rôles Deux types de base de mécanismes de contrôle d'accès sont utilisés pour empêcher l'accès non autorisé aux fichiers (et de manière plus générale à toute information) : DAC (Discretionary Access Control, pour contrôle d'accès arbitraire) et MAC (Mandatory Access Control, pour contrôle d'accès obligatoire). Par défaut, Linux utilise un mécanisme DAC : le créateur du fichier peut définir qui a accès à ce fichier. Un système MAC en revanche oblige tous les utilisateurs à suivre des règles dictées par l'administrateur. Le support grsecurity pour l'implémentation de MAC est nommée RBAC (Role Based Access Control). RBAC associé des rôles à chaque utilisateur. Chaque rôle définit quelles opérations peuvent être effectuées sur certains objets. Une fois que vous aurez un ensemble de rôles et d'opérations bien écrits, vos utilisateurs seront limités uniquement aux tâches que vous leur aurez données. Le rôle par défaut « deny-all » interdit aux utilisateurs d'effectuer une action à laquelle vous n'auriez pas pensé. La configuration du noyau recommandée pour le support de RBAC est :
gradm est un outil qui vous permet d'administrer et de maintenir une politique pour votre système. Vous pouvez activer ou désactiver le système RBAC, recharger les rôles RBAC, configurer un mot de passe pour le mode administrateur, etc. À l'installation de gradm, une politique par défaut sera installée dans /etc/grsec/policy :
Les politiques RBAC par défaut ne sont pas activées. C'est à l'administrateur système de choisir si le système utilisera des politiques RBAC et non celles de Gentoo. Avant d'activer le système RBAC, vous devez configurer un mot de passe administrateur.
Pour désactiver le système RBAC exécutez gradm -D. Si vous n'y êtes pas autorisé, vous devez auparavant vous approprier les rôles administrateur :
Si vous souhaitez abandonner le rôle administrateur, exécutez la commande gradm -u admin :
Le système RBAC propose unr fonctionnalité intéressante nommée « learning mode » (mode d'apprentissage). Le mode d'apprentissage peut générer une politique d'anticipation de privilèges pour votre système. Cela permet d'économiser temps et argent en déployant rapidement de nombreux serveurs sécurisés. Pour utiliser le mode d'apprentissage vous devez l'activer en utilisant gradm :
Maintenant, utilisez votre système, faites ce que vous feriez normalement. Essayez d'éviter de faire une synchronisation rsync, d'utiliser locate ou toute autre opération impliquant une manipulation lourde de fichiers. En effet, cela peut ralentir énormément votre système. Quand vous pensez avoir utilisé votre système suffisamment pour obtenir une bonne politique, indiquez à gradm qu'il peut commencer l'apprentissage et proposer des rôles dans le fichier /etc/grsec/learning.roles :
Vérifiez le fichier /etc/grsec/learning.roles et sauvegardez-le dans le fichier /etc/grsec/policy (avec les permissions 0600) une fois que vous avez fini.
Vous devriez maintenant pouvoir activer le système RBAC en utilisant la politique nouvellement apprise. Une fonctionnalité intéressante de grsecurity2 est le Set Operation Support (Support de la mise en place d'opérations) pour le fichier de configuration. Actuellement il supporte les unions, les intersections et les différences de sets (ou objets dans notre cas).
Voici un exemple d'utilisation et les objets résultant seront ajoutés à votre sujet :
Ce qui est équivalent à :
C'est le résultat de l'opérateur & qui récupère les deux sets et retourne la liste des fichiers qui sont présents dans les deux sets et les permissions de ces fichiers présentes dans les deux sets.
Cet exemple est équivalent à :
C'est le résultat de l'opérateur | qui récupère les deux sets et retourne les fichiers qui existent dans les deux. Si un fichier est dans les deux sets il récupère les permissions qui existent dans l'un ou l'autre des deux sets.
Cet exemple est équivalent à :
C'est le résultat de l'opérateur - qui prend les deux sets et retourne les fichiers existant dans le set de gauche mais pas dans le set de droite. Si un fichier est présent dans les deux (ou bien un répertoire parent existe dans le set de droite) il sera retourné et les permissions sur le fichier seront celles du fichier de gauche auxquelles on aura retiré les permissions données dans le second set. Dans un pseudo langage, vous pourriez l'interpréter ainsi :
L'ordre de priorité, de la plus forte à la plus faible, est le suivant : -, & |. Si vous ne voulez pas vous encombrer l'esprit avec les priorités d'opérations, le support des parenthèses est également fourni. Vous pouvez donc écrire, par exemple :
4. Protection des systèmes de fichiers Lutter contre le chroot et l'abus dans les systèmes de fichiers Grsecurity2 dispose de nombreux correctifs qui empêchent les utilisateurs d'obtenir une connaissance inutile à propos du système. Cela inclut notamment des restrictions sur l'utilisation de /proc, du chroot, l'utilisation de liens symboliques, etc. Nous vous recommandons la configuration de la protection des systèmes de fichiers suivante :
Activation du mécanisme de sécurité Lorsque vous utilisez un noyau compilé avec les options indiquées plus haut (ou des options similaires), vous pouvez activer ou désactiver plusieurs de ces options en utilisant le système de fichiers /proc ou en utilisant sysctl. L'exemple ci-dessous montre un extrait classique du fichier /etc/sysctl.conf :
Vous pouvez activer ou non les options à volonté en utilisant la commande sysctl :
Une option très importante de sysctl appartenant à grsecurity : kernel.grsecurity.grsec_lock. Quand elle est activée, vous ne pouvez plus changer aucune option.
Étendre votre possibilités de journalisation du système grsecurity ajoute une fonctionnalité supplémentaire au noyau appartenant à la journalisation. Avec l'audit de noyau de grsecurity, le noyau vous informera quand les applications sont exécutées, les périphériques (dé)montés, etc. Les différentes options d'audit du noyau La section de configuration du noyau suivante peut être utilisée pour activer les options d'audit du noyau de grsecurity :
Protection des fichiers exécutables Avec grsecurity vous pouvez restreindre les exécutables. Dans la mesure où la plupart des exploitations de failles fonctionnent à l'aide d'un ou plusieurs processus en exécution cette protection peut préserver la santé de votre système. La pile TCP/IP de Linux est vulnérable aux attaques basées sur la prédiction. Grsecurity propose des correctifs utilisant des procédés aléatoires pour contrer ces attaques. En plus de cela, vous pouvez également activer des restrictions sur les sockets, interdisant l'accès au réseau à certains groupes. Les options du noyau présentées ci-dessous activent plusieurs protections sur les exécutables et le réseau :
7. L'ensemble d'outils « Hardened » Même si ce n'est pas dans l'objectif de ce document, nous mentionnons l'utilisation de l'ensemble des outils « hardened » qui complète le modèle grsec/PaX du côté de l'espace utilisateur. Pour commencer rapidement, vous pouvez exécuter les commandes suivantes :
Si vous n'avez pas envie d'utiliser ce profil ajoutez les paramètres USE hardened pic pie à votre variable USE dans le fichier /etc/make.conf.
|
|