[Renforcement des fonctions de sécurité du noyau Linux – Partie 3] GrSecurity et PaX

Par Rédaction, secuobs.com
Le 14/11/2007

---

Résumé : GrSecurity permet de renforcer la sécurité des processus en mode userland, grâce à lui il est possible de rendre plus complexe l'exploitation d'une vulnérabilité par un attaquant sur un système d'exploitation. GrSecurity s'appuie notamment sur PaX pour les protections relatives au traitement de la mémoire kernel et user land - Lire l'article



GrSecurity propose une approche « amont » des renforcements de la sécurité du noyau. Par ce biais, la sécurité des processus en userland peut être également renforcée. Le noyau joue en effet un rôle majeur dans la gestion des processus. Il définit l'utilisation des plages mémoire (pile, tas, adresse de base du chargement des binaires, etc...) et les zones d'exécution, lecture ou écriture.

En combinant plusieurs techniques, il est possible de rendre particulièrement complexe l'exploitation de vulnérabilités présentes sur le système. Au meilleur des cas (sauf contournement des protections), un attaquant provoquera un déni de service sur le processus vulnérable (ce qui peut tout de même être critique en fonction de l'utilisation qui en est faite), ou de façon plus grave, sur le noyau.

GrSecurity se présente comme un patch kernel. Il est actualisé très régulièrement et est disponible à l'adresse suivante ( lien ).

De nombreuses fonctionnalités sont intégrées dans GrSecurity, dont la plus connue étant PaX qui permet d'ajouter plusieurs protections relatives au traitement de la mémoire kernel et user land.

Voici la liste des principales fonctionnalités de GrSecurity (de plus amples détails techniques sont disponibles sur le site officiel du projet) :

- Role-Based Access Control (RBAC), qui permet de faire une segmentation des restrictions de GrSecurity en fonction de nombreux critères : utilisateur, processus, fichier...
- Contrôle sur les fonctionnalités réseau de niveau 3
- Possibilités de capabilities pouvant être attribuées à des utilisateurs non root, et ce sans authentification préalable.
- Support de scripting dans la configuration (gestion de variables, d'opérateurs logiques, etc.)
- Gestion objets avec de possibles héritages pour les définitions d'ACL.
- Création et suppression dynamiques d'objets.
- Résolution temps réel des expressions régulières (traitement temporel possible)
- Protection de l'appel système ptrace (débogage dynamique pouvant être utilisé pour contourner certaines protections) en fonction de l'utilisateur et/ou du processus.
- Entrée /dev/grsec de devfs permettant un interfaçage kernel land / user land.
- Code « next-generation » qui produit des policies de moindres privilèges pour l'intégralité du système sans configuration nécessaire au préalable.
- Policies statiques configurables avec l'outil gradm.
- Possibilité de création dynamique des policies avec un mode learning qui permet de réduire considérablement le travail de l'administrateur système et de déboguer rapidement les problèmes classiques entraînés par l'usage d'ACL.
- Protection sur l'environnement, les noms de fichiers, etc.
- /proc/<pid>/ipaddr permet de lister l'adresse IP distante de l'utilisateur ayant initié une connexion ou lancé un processus réseau.
- Support de lecture/écriture/exécution des appels à ptrace
- Support des flags PaX pour protéger certains binaires uniquement, ou assouplir la politique sur d'autres (particulièrement pratique pour un serveur X par exemple).
- Protection sur les fonctions de la mémoire partagée (shared memory).
- Surveillance de certains flags propres au processeur (notamment dans le cadre de la lutte contre les codes offensifs) : trojans, spywares...
- Fonctions d'audit pouvant être appliquées à certains utilisateurs uniquement (restricted GID)
- Support de restrictions sur les ressources, sockets et capabilities.
- Protection contre les bruteforces d'adresses des exploits.
- Protection sur les fichiers de procfs /proc/[PID] (mémoire, mappages, etc.).
- Regénération des policies possible.
- Suppression configurable des logs.
- Configuration possible des processus liés à la gestion des comptes (création, suppression, modification...).
- Configuration intuitive et rapide.
- Indépendance du système de fichier et de l'architecture.
- Répercussions minimes sur les performances globales du système.
- Support des multi-processeurs (SMP).
- La plupart des opération s'effectue en complexité O(1).
- Activation/désactivation et rechargement dynamique des capabilities via procfs.
- Option permettant de cacher les processus utilisateurs aux autres utilisateurs « normaux » du système.
- Restrictions procfs (/proc) sur la diffusion d'informations aux « utilisateurs normaux », y compris sur les processus leur appartenant.
- Restrictions sur les liens symboliques et physiques (sur les inodes) afin de contrer les attaques de race conditions.
- Restrictions sur la pile (exécution, manipulation, etc.).
- Impossibilité aux utilisateurs « normaux » d'accéder aux informations de dmesg, informations souvent renvoyées par le noyau ou par les modules.
- Amélioration de l'implémentation du Trusted Path Execution (TPE)
- Restrictions socket par GID (Group ID).
- Grande flexibilité de la configuration grâce au support par syscontrol (sysctrl).
- Mécanisme de blocage des sysctl après configuration (lock).
- Alertes de sécurité remontées avec les informations réseau de l'attaquant (IP, éventuelle résolution DNS...)
- Arrêt automatique des processus relancés plusieurs fois dans un laps de temps réduit (bruteforces des exploits).
- Modes automatiques dans la configuration : low, medium et high
- Restrictions configurables sur les attaques par flood et/ou épuisement des ressources.
- Amélioration des générateurs d'aléa.
- PIDs (Processus ID) aléatoires.
- Ports sources TCP aléatoires
- Logs des exécutions (exécutables et arguments).
- Logs sur les tentatives d'accès au ressources non autorisées.
- Logs des appels à l'appel système chdir.
- Logs des appels à mount and unmount.
- Logs des signaux (SIGUP, SIGKILL...).
- Logs des erreurs aux appels à fork.
- Logs des changements de temps.
- PaX: Implémentation des accès utilisateurs aux pages mémoires non exécutables (protections sur les exploitations de ret-into-libc) avec une perte de performances négligeable sur les processeurs Intel.
- PaX: Implémentation des accès utilisateurs aux segments mémoires non exécutables (protections sur les exploitations de ret-into-libc) avec une perte de performances négligeable sur les processeurs Intel.
- PaX: Aléa des adresses de la pile (stack) et de l'adresse de base des fichiers chargés (mmap) sur de nombreuses architectures (i386, sparc, sparc64, alpha, parisc, amd64, ia64, ppc, et mips).
- PaX: Aléa des adresses du tas sur les architectures i386, sparc, sparc64, alpha, parisc, amd64, ia64, ppc, et mips.
- PaX: Aléa de l'adresse de base des exécutables pour les architectures i386, sparc, sparc64, alpha, parisc, amd64, ia64, et ppc.
- PaX: Aléa de la pile noyau (kernel stack).
- PaX: Emulation automatique par rebonds (adressage indirect) sur la libc : protection anti ret-into-libc (libc5, glibc 2.0, uClibc, Modula-3...).
- PaX: Emulation de la PLT (Procedure Linkage Table) permettant de charger en mémoire les adresses des fonctions à appeler à des adresses aléatoires.
- Modifications dynamiques du noyau impossibles via les pseudos fichiers /dev/mem, /dev/kmem, ou /dev/port.
- Options permettant d'interdire les accès directs aux écritures sur les entrées/sorties (raw IO).
- Pas d'attachement à la mémoire partagée de la part des processus chrootés.
- Pas d'appel à kill à l'intérieur d'un chroot.
- Pas d'appel à ptrace à l'intérieur d'un chroot.
- Pas d'appel à setpgid à l'intérieur d'un chroot.
- Pas d'appel à getpgid à l'intérieur d'un chroot.
- Pas d'appel à getuid à l'intérieur et extérieur d'un chroot.
- Impossibilité d'envoyer des signaux à des processus situés en dehors du chroot en cours.
- Impossibilité de lister les processus en dehors d'un chroot.
- Impossibilité de monter/démonter des partitions à l'intérieur d'un chroot.
- Pas d'appel à la fonction « pivot » à l'intérieur d'un chroot (méthode d'évasion connue).
- Impossibilité de faire des doubles chroots (méthode d'évasion connue).
- Pas de fchdir en dehors d'un chroot
- Renforcement de l'appel à chdir("/") dans un chroot
- Impossibilité de suider (chmod +s) des binaires à l'intérieur d'un chroot.
- Impossibilité de créer des fichiers spéciaux à l'aide de mknod à l'intérieur d'un chroot.
- Pas d'écriture sysctl à l'intérieur d'un chroot.
- Impossibilité de changer les priorités de l'ordonnanceur à l'intérieur d'un chroot (nice).
- Impossibilité de se connecter aux sockets abstraites UNIX situées en dehors d'un chroot.
- Logs des exécutions à l'intérieur d'un chroot.


L'outil gradm (disponible sur le site de grsecurity : lien ) et paxctl (disponible sur le site de PaX : lien ) permettent d'alléger ou d'augmenter les restrictions GrSecurity/PaX sur les binaires, et ce de façon unitaire. Il est alors possible d'exclure par exemple des binaires sur les protections en vigueur sur le système.

L'installation est très simple et rapide. Il suffit de récupérer le dernier patch en date sur le site de GrSecurity et de l'installer :

gunzip grsecurity-2.1.8-2.6.14.6-200601211647.patch.gz
cp grsecurity-2.1.8-2.6.14.6-200601211647.patch linux
cd linux
patch -p1 < grsecurity-2.1.8-2.6.14.6-200601211647.patch
patching file security/security.c
(...)


La configuration s'effectue ensuite de façon classique avec un make menuconfig par exemple.

GrSecurity et Pax sont placés dans le menu « Security options », tout comme SELinux, au même titre que les autres moyens de protection bas niveau :

Linux Kernel v2.6.16.9 Configuration
Linux Kernel Configuration
x x Code maturity level options --->
x x General setup --->
x x Loadable module support --->
x x Block layer --->
x x Processor type and features --->
x x Power management options (ACPI, APM) --->
x x Bus options (PCI, PCMCIA, EISA, MCA, ISA) --->
x x Executable file formats --->
x x Networking --->
x x Device Drivers --->
x x File systems --->
x x Instrumentation Support --->
x x Kernel hacking --->
x x Security options --->
x x Cryptographic options --->
x x Library routines --->
x x ---
x x Load an Alternate Configuration File
x x Save Configuration to an Alternate File


Dans le menu « Security options », PaX et GrSecurity sont dissociés. Cependant GrSecurity propose également des fonctionnalités relatives à la gestion de la mémoire :

PaX --->
Grsecurity --->
[*] Enable access key retention support
[*] Enable the /proc/keys file by which all keys may be viewed
[*] Enable different security models
[*] Socket and Networking Security Hooks
<*> Default Linux Capabilities
< > Root Plug Support
<*> BSD Secure Levels


Pour Pax, les sous-menus permettent de configurer finement la protection mémoire :

[*] Enable various PaX features
PaX Control ---> Non-executable pages ---> Address Space Layout Randomization --->


La configuration de GrSecurity s'effectue sur le même modèle :

[*] Grsecurity
Security Level (Custom) --->
Address Space Protection --->
Role Based Access Control Options --->
Filesystem Protections --->
Kernel Auditing --->
Executable Protections --->
Network Protections --->
Sysctl support --->
Logging Options --->


Détailler toutes les options de GrSecurity serait beaucoup trop long (la documentation officielle elle-même passe rapidement sur ces fonctionnalités). Pour chaque fonction proposée, une aide détaillée en anglais permet de comprendre les rôles précis. Pour y accéder, vous devrez vous placer sur la fonction dont vous souhaitez obtenir l'aide, puis presser la touche « ? ».

Attention cependant à l'option « Runtime module disabling », déconseillée la plupart du temps, sauf si vous désirez interdire ou restreindre de façon drastique l'utilisation des modules (LKM : Linux Kernel Module).

La fonction « sysctl enable » est également déconseillée car elle permet de « bypasser » aisément GrSecurity si le verrou sysctl n'est pas placé correctement. Ne l'activez donc pas si vous n'en connaissez pas exactement le rôle.

L'approche « W^X » (à lire « Write XOR eXecute ») permet de ne pas activer une section mémoire en écriture et en exécution simultanément. De fait, un shellcode placé par un utilisateur ne pourra pas y être exécuté. Il existe cependant encore des moyens de contourner cette dernière technique... Comme toujours !


Autres ressources dans ce dossier :

[Renforcement des fonctions de sécurité du noyau Linux – Partie 1] Présentation – lien

[Renforcement des fonctions de sécurité du noyau Linux – Partie 2] Address Space Layout Randomization – lien

[Renforcement des fonctions de sécurité du noyau Linux – Partie 4] SELinux (1) – lien

[Renforcement des fonctions de sécurité du noyau Linux – Partie 5] SELinux (2) – lien

[Renforcement des fonctions de sécurité du noyau Linux – Partie 6] Netfilter, conclusions & webographie – lien