Définition des politiques

1 type=DTE audit(1285243100:4600) avc:granted { execute } for pid=1576 comm="%

systemroot%\explorer.exe" ppid=1576 path="%systemroot%\system32\cmd.exe"

scontext=system_u:system_r:explorer_t tcontext=system_u:object_r:systemroot

|system32|cmd_exec_t tclass=process

Listing 5.16 – Extrait d’un fichier d’audit autorisant une interaction

Une fois que l’administrateur considère avoir réalisé toutes les interactions nécessaires pour que son programme puisse fonctionner et avant de passer le moniteur en mode protection, ce qui pourrait bloquer la machine, il peut valider sa politique dans le mode détection en vérifiant les traces générées.

Ce mode peut aussi se révéler utile dans des environnements où seule la détection des interac-tions est voulue.

Mode protection (Requête/Réponse)

Le mode protection, ouenforcing, est le mode dans lequel le moniteur applique les décisions.

Si une interaction n’est pas dans la politique de contrôle d’accès, alors elle sera bloquée par le moniteur et une trace sera générée pour notifier l’administrateur de ce refus.

5.1.4 Définition des politiques

Les politiques de contrôle d’accès peuvent être écrites soit de façon manuelle, soit de manière automatique grâce à l’outil que nous proposons. Nous allons dans cette section détailler les deux fonctionnements.

Automatisation

Nous proposons un outil pour la création automatique d’une politique de contrôle d’accès, quel que soit le modèle de protection. Grâce à cette automatisation, la politique s’écrit par répétition.

Pour réaliser cet apprentissage, il est nécessaire de mettre le moniteur en mode détection, ainsi le programme ou processus pour lequel on veut créer la nouvelle politique ne sera pas bloqué.

Prenons un exemple illustré par la figure 5.1. Nous désirons ici ajouter un programme sur notre système d’exploitation, il faut donc ajouter les règles d’accès correspondantes pour qu’il puisse fonctionner correctement. Ce mode peut fonctionner avec ou sans politique de base. Si le moniteur n’a pas de politique de base, il va enregistrer toutes les interactions faites sur le système, même celles qui ne sont pas réalisées par le programme que l’on veut ajouter.

La méthodologie d’apprentissage est la suivante. On change le mode du moniteur en détection.

On lance une première fois le nouveau programme (flèche 0 du schéma). Le moniteur trace les interactions du processus (flèche 1) et les enregistre dans le fichier d’audit (flèche 2). Notre outil parcourt le fichier d’audit (flèche 3) et transforme automatiquement les traces en règles d’accès au bon format, c’est-à-dire PBACouDTE. Ces nouvelles règles sont ajoutées à la politique courante (flèche 4) puis cette nouvelle politique est rechargée par le moniteur (flèche 5). Le processus ou programme que l’on veut ajouter est ensuite relancé.

La fin du processus d’apprentissage est laissée à la discrétion de l’administrateur. En effet, il n’est pas possible de déterminer de manière certaine quand un programme a réalisé toutes les interactions de manière automatique. Par exemple, pour une application graphique, il faut que l’administrateur réalise lui-même les tâches qu’il souhaite autoriser. Il est donc conseillé d’avoir unecheck-listprécisant les tâches nécessaires au moment de lancer l’apprentissage.

L’apprentissage peut être considéré comme terminé lorsqu’on a réalisé toutes les tâches listées dans lacheck-listet qu’il n’apparaît plus aucune trace d’accès bloqué.

FIGURE5.1 – Schéma décrivant l’apprentissage d’une politique

Avantages Le principal avantage de cette méthode d’écriture de la politique de contrôle d’accès est sa grande facilité de mise en place. En effet, il suffit de lancer le programme d’apprentissage et de réaliser les tâches nécessaires au sein du programme que l’on veut ajouter pour que les règles soient automatiquement générées. En plus de facilité l’écriture, cela l’accélère aussi. De plus, si l’administrateur a minutieusement réalisé toutes les tâches désirées au sein du nouveau pro-gramme, il ne devrait pas avoir à modifier plus tard sa politique. Cependant, lors d’une mise à jour du programme, il peut être nécessaire de recommencer l’opération pour ajouter automatiquement les nouvelles règles dans la politique mais les tâches sont prédéfinies.

Inconvénient Le principal inconvénient de cette méthode est la nécessité pour l’administrateur de vérifier, à la main, les règles qui ont été ajoutées par l’outil dans la politique. En effet, il est possible que le programme que l’on veuille ajouter, réalise des interactions malveillantes ou illégi-times pour l’administrateur, cachées par des tâches "normales". Par exemple, on pourrait imaginer un programme qui tente de copier la partie du registre contenant les mots de passe des utilisateurs.

Lors de la phase d’apprentissage, cette interaction ne sera pas bloquée par le moniteur et par ap-prentissage, elle sera ajoutée à la politique courante. Si l’administrateur ne vérifie pas les règles, cette interaction malveillante sera aussi autorisée même en mode protection.

Il est donc nécessaire pour l’administrateur de vérifier les règles qui ont été ajoutées pour un programme. C’est pour cela que nous conseillons d’avoir au préalable une politique déjà écrite prenant en compte le reste du système, pour ne pas être parasité par les autres applications.

Manuelle

La seconde méthode pour créer une politique est de le faire de façon manuelle. Nous pouvons définir deux cas : soit l’administrateur connait précisément ce que fait le programme qu’il veut ajouter, dans ce cas, il écrit toutes les règles, soit il utilise la même méthode que pour l’automati-sation, en transformant manuellement les traces en règles d’accès.

Dans les deux cas, le moniteur peut être utilisé soit en mode détection pour plus de facilité, soit en mode protection.

Avantages Le principal avantage de cette méthode est que l’administrateur maîtrise entièrement le processus de création des règles d’accès. Il peut ainsi vérifier qu’il n’autorise pas une interaction malveillante ou illégitime pour le nouveau programme.

Inconvénient Le principal inconvénient est que cette méthode est beaucoup plus coûteuse en temps. En effet, la retranscription à la main de chaque règle peut se révéler être un travail très fastidieux, surtout dans le cas des mises à jour des programmes qui les modifient intégralement, voire pour les mises à jour du système.

5.1.5 Discussion

Nous venons de détailler l’implantation choisie pour les modèles de protection PBACetDTE

appliqués aux systèmes Windows. Dans cette section, nous avons dû résoudre la problématique des ressources.

Pour le modèle de protection PBAC, nous avons choisi d’implanter le mécanisme de namespaceen utilisant les variables d’environnement. Ces variables sont divisées en deux types : le premier est géré directement par le système. On le retrouve ainsi sur tous les systèmes Windows.

Cela assure une portabilité complète de nos politiques de contrôle d’accès. Le second type est géré par l’administrateur. Il peut ainsi ajouter des variables d’environnement pour rédiger des règles

d’accès propres à son système ou à son parc de machines. Nous avons aussi ajouté à ce modèle de protection, un second modèle de protection nomméTPE. Il permet de définir des répertoires de confiance d’où seront lancés les fichiers exécutables.

En ce qui concerne le modèle de protectionDTE, la principale difficulté était de trouver un moyen de stocker les contextes de sécurité des objets. Nous avons vu que SELinux utilisait les attributs étendus du système de fichiers pour les stocker. Cette solution n’est pas portable sur les systèmes Windows qui n’utilisent pas le même système de fichiers. Nous avons ainsi proposé une méthode évitant d’avoir à stocker les contextes de sécurité. Afin de ne pas créer de faiblesse dans notre modèle de protection, nous avons dû définir des contextes de sécurité plus précis que ceux proposés par SELinux. Pour cela, nous avons choisi de mettre dans le type du contexte de sécurité objet le chemin complet de l’objet. Cette méthode conduit à avoir les mêmes problèmes que pour le modèlePBAC, à savoir un problème dans le mécanisme de noms des ressources. Pour résoudre ce problème, nous avons utilisé la même solution que pour le modèle PBAC. Nous avons donc utilisé les variables d’environnement pour la définition des chemins complets des objets.

Grâce à l’implantation basée sur les variables d’environnement nous proposons donc des noms symboliques absolus indépendants de la localisation tels que définit dans le chapitre 3. Nous of-frons donc un mécanisme permettant de désigner de manière précise chaque ressource du système.

Nous avons montré que nous pouvions appliquer cette méthode non seulement sur les ressources du système de fichiers mais aussi sur les éléments du registre, mécanisme important dans les sys-tèmes Windows.

Nous avons aussi détaillé les deux modes de fonctionnement de notre moniteur de référence.

Le mode détection, qui va permettre d’écrire une politique de contrôle d’accès et un mode pro-tection, qui l’applique strictement. Grâce au mode dépro-tection, nous avons mis en place un outil qui automatise la création de nouvelles règles pour l’ajout d’un nouveau programme. Cette automa-tisation n’est pas sans risque puisque l’outil n’effectue aucun contrôle sur la légitimité des règles ajoutées. Il est donc nécessaire que l’administrateur vérifie les règles générées.

Enfin, nous avons présenté notre mécanisme d’audit, qui génère des traces permettant de connaître les interactions qui se sont déroulées sur le système, mais qui sont aussi utilisées pour créer des règles de contrôle d’accès, que ce soit de façon automatique ou manuelle.