![[Photo de l'auteur]](../../common/images/Serge-Lozovsky.jpg)
original in en Serge Lozovsky
en to fr Jean Peyratout
Vingt ans d'expérience dans les systèmes d'information en tant que programmeur / gestionnaire. 5 ans de technologie Internet, 9 ans d'UNIX, 4 ans d'Intelligence Artificielle (représentation de la connaissance et des données).
Serge Lozovsky présente un package logiciel qu'il a développé pour rendre les systèmes UNIX plus sûrs. Le logiciel est disponible sous une licence non libre. Il est possible de l'utiliser gratuitement pour un usage éducatif non commercial.
L'un des problèmes principaux d'UNIX en matière de sécurité est que le superutilisateur peut faire tout ce qu'il veut avec le système. Il y a des programmes (daemons) qui travaillent avec les privilèges du superutilisateur, comme par exemple popd ou sendmail, et qui sont accessibles depuis le réseau (Internet / Intranet). Or il peut y avoir des bugs dans un programme, quel qu'il soit. Quelqu'un voulant pénétrer le système se connecte via le réseau à un tel programme, exploite les bugs qu'il y trouve et prend ainsi le contrôle de toutes les machines.
VXE (Virtual eXecuting Environment, environnement virtuel d'exécution) protège les serveurs UNIX d'intrusions de ce type, des attaques de crackers depuis le réseau, etc. Il protège les sous-systèmes logiciels, comme SMTP, POP, HTTP et n'importe quel autre sous-système déjà installé sur le serveur. Il n'est pas nécessaire de changer la configuration des logiciels existants, simplement de la PROTÉGER.
VXE résout donc les problèmes suivants : il protège la machine hôte et les sous-systèmes particuliers qui tournent avec les droits du superutilisateur et peuvent être susceptibles de bugs. C'est la situation que l'on rencontre dans la vie réelle.
![[Illustration]](../../common/images/illustration133.jpg)
Virtual eXecuting Environment (VXE) protège la machine hôte et les sous-systèmes particuliers qui tournent avec les droits du superutilisateur et peuvent être susceptibles de bugs. Quand un programme tourne en mode superutilisateur, il peut accéder à toutes les ressources du système d'exploitation (OS). VXE crée un environnement virtuel pour chaque sous-système. Dans un environnement de ce type, seules les ressources nécessaires aux opérations normales sont visibles et disponibles pour le sous-système (le programme de démarrage et tous les sous-processus qui en découlent). Chaque sous-processus tourne dans le même VXE que le processus parent. Pour modifier des ressources système, le programme utilise des appels système (syscalls). VXE a les moyens de décrire ces appels système, avec les paramètres disponibles pour chaque sous-système. Par exemple, il peut être défini (pour des appels système concernant les opérations sur les fichiers) que certains fichiers peuvent être lus, d'autres exécutés, que les opérations réseau ne sont pas possibles (dans le cas d'un serveur POP, il maintient la connexion réseau, mais il n'en crée pas de nouvelles) et ces restrictions ne peuvent être contournées par le programme, même avec des privilèges de superutilisateur.
Ces restrictions peuvent être aussi astucieuses que nécessaire. Si un intrus prend le contrôle d'un tel sous-système, il ne peut pas utiliser les méthodes habituelles pour "sniffer" de l'information ou modifier le système. Tout ce qu'il peut en théorie faire, en utilisant des méthodes sophistiquées, c'est de modifier le fonctionnement du sous-système qu'il a réussi à contrôler, mais pas le système lui-même, ni d'autres sous-systèmes. J'entends, comme méthodes habituelles, celles où un intrus prend les privilèges du superutilisateur et lance un interpréteur de commandes (shell) et les utilitaires habituels, éditeur de texte, utilitaire de copie, etc. Il ne peut rien faire avec ce genre d'utilitaires. Par exemple, un serveur POP n'a pas besoin d'un éditeur de texte ou d'un utilitaire de copie pour remplir sa tâche, donc il n'y a pas ce genre de programme dans l'environnement VXE créé pour la protection d'un POPD.
Plus exactement, VXE protège le système et ses sous-systèmes des interférences du sous-système piraté (tournant sous le contrôle de VXE). Et, comme effet supplémentaire, il offre une protection au sous-système lui-même (de la façon décrite ci-dessus). Pour faire simple, dans ce qui suit, nous dirons que VXE protège le sous-système.
La description VXE (VXED) est un petit programme LISP (un ensemble de fonctions) qui utilise une description déclarative des paramètres que l'on peut accepter pour les différents appels système. Ce VXED est chargé dans le noyau (kernel) où il contrôle les paramètres des appels système des sous-systèmes spécifiés. Les VXEDs sont donc des modules chargeables de façon dynamique, maintenus par le petit interpréteur LISP. Dans la version courante de VXE, c'est vxelisp, dérivé de RefLisp (Bill Birch bbirch@ctp.com). vxelisp représente différemment les longues chaînes d'instructions, et a un jeu complet de fonctions "string and bit". Enfin, vxelisp est "réentrant", ce qui permet de maintenir simultanément plusieurs VXEDs différents.
Il y a deux méthodes pour activer VXED : explicite et implicite (automatique). L'activation explicite se fait en utilisant le programme vxe. Les paramètres sont le chemin d'accès à VXED ainsi que le chemin et les paramètres de l'exécutable qui sera lancé avec des restrictions. Pour la méthode automatique, l'utilitaire vxed précharge tous les VXEDs nécessaires dans le noyau. Chaque VXED a un modèle d'activation. Au lancement du programme (exec), le noyau compare le chemin d'accès de l'exécutable au modèle et le VXED correspondant est activé. Cette méthode peut être utilisée pour activer la protection au démarrage d'un programme quelonque dans un répertoire spécifié (et tous ses sous-répertoires). Par exemple, pour protéger des scripts CGI appelés par des utilisateurs, des VXEDs peuvent être définis pour chaque sous-répertoire utilisateur.
Tout VXED sophistiqué peut être créé à la main, en utilisant toute la puissance de vxelisp. Mais VXE ne contraint pas pour autant les administrateurs à apprendre et à utiliser LISP. On peut penser à VXE comme un système capable d'auto-apprentissage. Le système de développement de VXE (DS) lance VXE en mode trace.
Un lancement de ce type conserve les descriptions des appels systèmes (utilisés) permis. La création et la modification d'un VXED se fait via une interface WWW. Le système de développement supporte deux types de VXED : les types "strict"et "système de fichier". Le VXED strict décrit explicitement tous les appels système autorisés. Le VXED "système de fichiers" décrit les permissions en lecture, écriture et exécution pour un chemin donné. Les restrictions spécifiées s'appliquent aux appels système du système de fichiers, tous les autres appels système sont autorisés. Une fois que le VXED a été créé par un sous-système donné, il fonctionne en mode souple. Dans ce mode, toutes les violations de VXED sont enregistrées, mais les appels système peuvent être effectués. VXE DS peut mettre à jour VXED automatiquement, en utilisant l'information enregistrée.
Bien sûr, les modifications nécessaires dans VXED peuvent être effectuées à la main en utilisant l'éditeur VXED. Des violations peuvent être causées par un intrus ou par une modification dans le comportement du sous-système dans diverses circonstances. L'administrateur VXE consulte le log (l'enregistrement) à l'aide du DS et décide si une mise à jour est justifiée. S'il n'y a pas de violations, le VXED peut être basculé en mode production. Dans ce mode, les violations sont enregistrées et les appels système sont bloqués (échec). Une fois de plus, le log peut être utilisé pour la détection d'un intrus ou pour le réglage fin de VXED.
Pour des raisons de sécurité, toutes les actions de contrôle de VXE ne peuvent être effectuées qu'en mode superutilisateur et à l'extérieur de VXE.
VXE modifie les performances de la façon suivante : si un programme se lance à l'extérieur de VXE, chaque appel système exécute deux instructions assembleur supplémentaires. Il vérifie si VXE est concerné par le processus courant, et il passe la main si ce n'est pas le cas. Pour chaque appel système exec, une petite sous-routine en C vérifie s'il y a un VXED convenable déjà disponible dans le noyau. Pour les programmes qui tournent dans VXE, quelques lignes de code C contrôlent si la vérification de paramètre est requise. Certains appels système peuvent être indiqués à VXED comme ne devant pas être vérifiés (par exemple, par défaut, les opérations de lecture et d'écriture). Et ce n'est que le reste des appels système qui est vérifié par de très petites fonctions LISP. Ces fonctions se trouvent dans VXED et l'administrateur peut facilement les observer.
support de VXE : vxe@intes.odessa.ua
page de VXE : http://www.intes.odessa.ua/vxe