Résumé technique : TOMOYO Linux – Une méthode de contrôle d'accès obligatoire basée sur l'état d'exécution des applications

1. Énoncé du problème

Les méthodes conventionnelles de contrôle d'accès, incluant le contrôle d'accès discrétionnaire (DAC) et les implémentations standards de contrôle d'accès obligatoire (MAC) (qu'elles soient basées sur des étiquettes ou sur des chemins de fichiers), prennent des décisions d'accès basées principalement sur la combinaison d'un sujet (application/processus) et d'un objet (fichier/ressource). Ces méthodes ne parviennent pas à prendre en compte l'état d'exécution de l'application ou l'intention derrière une demande d'accès spécifique.

Le document identifie deux limitations critiques dans les systèmes existants :

1. Manque de conscience contextuelle : Les méthodes conventionnelles ne tiennent pas compte de la manière dont une application a été lancée ou de ce qu'elle est sur le point de traiter. Par exemple, un navigateur Web (client HTTP) devrait avoir des permissions d'accès différentes selon qu'il s'exécute en tant qu'application utilisateur ou en tant que script CGI invoqué par un serveur Web. De même, le comportement d'une application peut changer en fonction des arguments de la ligne de commande ou des variables d'environnement (par exemple, sshd affichant un fichier de bannière qui contient des données sensibles en cas de mauvaise configuration).
2. Sandboxing à grain grossier : Parce que l'état d'exécution est ignoré, les bacs à sable (sandboxes) basés sur le MAC conventionnel sont souvent trop grossiers. Ils ne peuvent pas restreindre des opérations spécifiques (comme renommer un fichier de configuration en un fichier de contenu) sans bloquer l'application entière, ce qui conduit à une localisation insuffisante des dommages.

Le problème central est que le contrôle d'accès conventionnel ne peut pas distinguer le même fichier exécutable s'exécutant dans des contextes différents (par exemple, un shell connecté via SSH vs un shell connecté via une console vs un shell lancé par un serveur Web), ni évaluer les effets potentiels de l'octroi d'une demande d'accès spécifique.

2. Méthodologie

Les auteurs proposent une nouvelle méthode de contrôle d'accès qui incorpore l'historique d'exécution de l'application et l'intention de traitement dans le processus de décision. Cette méthodologie est implémentée dans TOMOYO Linux, un module de sécurité Linux (LSM).

2.1 Historique d'exécution du programme

Le système suit l'« historique d'exécution du programme » pour chaque processus. Cet historique est une liste des noms de chemins de toutes les applications exécutées depuis le démarrage du système (<kernel>) jusqu'à la création du processus actuel.

• Mécanisme : Lorsqu'un processus effectue un fork et exécute une nouvelle application (via execve), le processus enfant hérite de l'historique de son parent et y ajoute son propre nom de programme.
• Résultat : Même si deux processus exécutent le même binaire (par exemple, /bin/bash), ils possèdent des historiques d'exécution différents s'ils ont été lancés via des chaînes différentes (par exemple, init $\to$ agetty $\to$ login $\to$ bash vs init $\to$ sshd $\to$ bash).

2.2 Classification par domaines

Sur la base de l'historique d'exécution, le système définit des Domaines.

• Un domaine est un identifiant unique représentant un état d'exécution spécifique, partant de <kernel> et suivant la chaîne d'exécution.
• Les politiques de contrôle d'accès sont définies par domaine, et non par binaire. Cela permet à l'administrateur système d'accorder des permissions différentes à la même application selon la manière dont elle a été lancée.
• La structure des domaines forme un arbre, permettant des capacités de contrôle d'accès basé sur les rôles (RBAC) où les shells imbriqués ou les élévations de privilèges (par exemple, su) créent de nouveaux domaines distincts avec des permissions spécifiques et limitées.

2.3 Décisions d'accès basées sur des conditions

Le langage de politique permet de conditionner les décisions d'accès à divers paramètres gérés au sein du noyau, notamment :

• Arguments de la ligne de commande : Restreindre l'exécution sur la base de drapeaux spécifiques (ex: exec.argv[0]="passwd").
• Variables d'environnement : Filtrer en fonction des paramètres de proxy ou des chemins de recherche.
• Attributs de fichiers : Vérifier les permissions de fichiers, la propriété ou le contenu spécifique des fichiers.
• Identifiants d'utilisateur (UID) : Restreindre l'accès en fonction de l'ID utilisateur effectif ou réel.

En utilisant ces facteurs comme conditions, le système peut inférer l'« intention » de l'application. Par exemple, il peut autoriser une opération de lecture de fichier uniquement si l'application est exécutée avec des arguments spécifiques indiquant une tâche administrative légitime, plutôt qu'une lecture générique.

2.4 Implémentation via un moniteur de référence

TOMOYO Linux implémente un moniteur de référence au sein du noyau Linux en utilisant le framework LSM.

• Interception : Les appels système sont interceptés (hooks) pour intercepter les demandes d'accès.
• Décision : Le noyau vérifie la requête par rapport à la politique définie pour le domaine actuel du processus.
• Application : Si la requête correspond à la politique (incluant tous les paramètres obligatoires et optionnels), elle est autorisée ; sinon, elle est rejetée.
• Approche par liste blanche : Le système fonctionne sur la base d'une liste blanche ; tout ce qui n'est pas explicitement autorisé est refusé.

3. Contributions clés

1. Conscience de l'état d'exécution : Le papier introduit une méthode pour identifier de manière unique l'état d'exécution d'une application en utilisant une chaîne d'historiques d'exécution de programmes, permettant un contrôle d'accès fin que le MAC conventionnel ne peut atteindre.
2. Politique basée sur l'intention : La méthodologie permet de définir des politiques basées sur le traitement qu'une application est sur le point d'effectuer (inféré à partir des arguments, de l'environnement et de l'historique), plutôt que simplement sur l'identité du sujet et de l'objet.
3. Implémentation TOMOYO Linux : Les auteurs fournissent une implémentation complète de cette méthode dans le noyau Linux, comprenant :
   • Un éditeur de politique (CUI) pour définir et gérer les domaines.
   • Un « Mode Apprentissage » (Learning Mode) qui génère automatiquement des politiques en observant le comportement du système, facilitant ainsi le déploiement.
   • Le support des caractères génériques (wildcards) et des expressions conditionnelles complexes dans les définitions de politiques.
4. Intégration RBAC : La structure des domaines supporte naturellement le contrôle d'accès basé sur les rôles, permettant aux administrateurs de définir des rôles basés sur la hiérarchie d'exécution des processus (par exemple, un shell lancé par su possède des permissions différentes du shell de connexion original).

4. Résultats et évaluation

Le papier présente une évaluation de TOMOYO Linux basée sur une expérience de démonstration et des tests de performance (benchmarks).

4.1 Utilisabilité et gestion

• Formulation de la politique : Le « Mode Apprentissage » permet aux administrateurs d'observer le système pendant une période donnée (par exemple, deux semaines pour un serveur web) afin de collecter les historiques d'exécution et les modèles d'accès. Cela réduit considérablement l'effort manuel requis pour définir les politiques par rapport au MAC basé sur les étiquettes (comme SELinux), où les administrateurs doivent mapper manuellement des transitions d'étiquettes complexes.
• Démonstration : Dans une expérience de 2007 sur un serveur web, les participants ont pu comprendre les principes et éditer les politiques rapidement. L'utilisation des noms de chemins et de l'historique d'exécution a rendu le comportement du système transparent pour les administrateurs.
• Comparaison avec SELinux : Contrairement à SELinux, qui nécessite de comprendre des transitions d'étiquettes complexes et des politiques standards qui peuvent ne pas correspondre à l'environnement spécifique, TOMOYO permet de définir des politiques indépendamment par domaine, rendant la gestion plus intuitive.

4.2 Efficacité de la sécurité

La méthode se montre efficace contre :

• Exécution d'applications non autorisées : Empêcher l'exécution de shells ou d'outils non autorisés même si une application vulnérable est compromise, en restreignant les permissions du domaine spécifique.
• Traversée de chemin (Path Traversal) : Annuler les attaques en calculant des chemins absolus basés sur les structures de données du noyau.
• Attaques par liens symboliques : Restreindre la création de liens symboliques à moins qu'ils ne soient explicitement permis pour le répertoire et la cible spécifiques.

4.3 Impact sur les performances

Les performances ont été mesurées avec LMBench sur un système Ubuntu 10.04 (Core 2 Duo, 2 Go de RAM).

• Appels système non interceptés : Les appels système non interceptés par TOMOYO ont montré un impact négligeable (dans une marge de ±5 %, attribuée à la variance de mesure).
• Appels système interceptés :
  • Opérations de fichiers : Un overhead significatif a été observé pour les opérations impliquant la création de fichiers et les métadonnées (ex: stat, open/close, 0K File Create), avec des délais allant de ~60 % à ~128 %. Cela est dû à la surcharge de la vérification des noms de chemins et des permissions.
  • Création de processus : Les opérations fork et execve ont montré un délai d'environ 5 à 15 %, attribué au traitement de l'héritage de l'historique d'exécution.
  • Réseau : Les opérations TCP ont montré un overhead minimal (~1 %), tandis que l'UDP a montré ~28 %.
• Échelle de la politique : Le papier note qu'à mesure que le nombre de domaines et de permissions d'accès augmente, les temps de recherche augmentent. Cependant, les données empiriques suggèrent que dans les déploiements typiques, le nombre de domaines et de règles par domaine reste inférieur à 2 000, maintenant la dégradation des performances dans des limites acceptables pour un usage ordinaire.

5. Signification et revendications

Le papier affirme que TOMOYO Linux représente une avancée significative dans le contrôle d'accès obligatoire en déplaçant l'attention des paires statiques sujet-objet vers des états d'exécution dynamiques.

• Complémentarité : Les auteurs positionnent cette méthode non pas comme un remplacement du MAC basé sur les étiquettes, mais comme un complément. Alors que le MAC basé sur les étiquettes excelle dans la prévention des fuites d'informations grâce à une isolation robuste, TOMOYO excelle dans le maintien de l'état correct d'un système d'information et dans la prévention des applications effectuant des opérations non intentionnelles.
• Praticité : En utilisant les informations existantes du noyau (historique d'exécution, arguments, environnement) plutôt que d'exiger des modifications d'applications ou des assignations d'étiquettes complexes, la méthode offre une voie pratique vers un contrôle d'accès fin.
• Utilisabilité : La capacité de générer des politiques par observation (Mode Apprentissage) et la nature intuitive de l'historique d'exécution répondent à la barrière à l'entrée élevée souvent associée aux systèmes MAC.

Le papier conclut qu'en rejetant les demandes d'accès non autorisées et inutiles que les méthodes conventionnelles ne peuvent identifier, TOMOYO Linux améliore la sécurité de l'information tout en restant gérable pour les administrateurs système. Des travaux futurs sont suggérés pour combiner cette méthode avec des déclarations d'applications afin d'affiner davantage la précision de l'état d'exécution.