previous up next top index
Précédent : Architectures à métaobjets et tolérance Remonter : Action de recherche Suivant : Evaluation quantitative de la sécurité


Protection et noyaux de sécurité

  Participants : Yves Deswarte, Jean-Charles Fabre, Vincent Nicomette, David Powell, Eric Totel

Après avoir réalisé un serveur de sécurité réparti tolérant les fautes accidentelles et les intrusions dans le cadre du projet ESPRIT Delta-4, nous nous intéressons maintenant davantage à la gestion des droits d'accès, basée sur la notion de noyau de sécurité. Un noyau de sécurité est un composant du système qui, s'il est sûr, garantit que la politique de sécurité est respectée. Ce noyau de sécurité met en oeuvre des mécanismes généraux (labels, capacités) sur des objets de fine granularité, tout en permettant une grande souplesse sur le choix de la politique de sécurité.

Nous avons élaboré un premier schéma d'autorisation mettant en oeuvre des noyaux de sécurité dans les systèmes d'objets distribués [8, 7, 2]. Un système d'objets distribués est composé d'un ensemble d'objets dont la localisation est transparente aux utilisateurs. Certains de ces objets sont directement connus des utilisateurs (ce sont des objets persistants) et peuvent être invoqués grâce à des méthodes publiques. En revanche, il existe de nombreux objets temporaires, dédiés à la réalisation d'une action ponctuelle. De même, il existe des objets persistants mais dont la granularité est si fine que leur existence est totalement inconnue des utilisateurs d'un tel système.

Le schéma d'autorisation met en oeuvre deux niveaux de protection. La gestion des droits d'accès relatifs aux objets persistants et de forte granularité est prise en charge par un serveur d'autorisation. Le serveur d'autorisation est responsable de la fourniture aux utilisateurs des privilèges leur permettant d'accéder à des objets persistants. Ces privilèges seront délivrés seulement si l'utilisateur est autorisé à effectuer l'accès correspondant (le serveur d'autorisation gère une matrice d'accès). Nous avons donné à ce serveur d'autorisation une grande souplesse quant à la gestion des droits d'accès, tout en garantissant au mieux le principe du moindre privilège.

Ce schéma d'autorisation est adaptable à différentes politiques de sécurité. En particulier, nous avons développé une politique obligatoire multi-niveau permettant de garantir des propriétés de confidentialité. Cette politique est une adaptation au modéle objet de la politique de Bell et LaPadula, et comme elle assigne des labels aux différentes entités du systèmes : habilitation pour les utilisateurs, classification pour les objets à état, intervalle de confiance pour les objets sans état et parenthèse pour les activités. La politique ainsi obtenue est plus souple que celle de Bell-LaPadula, en ce qu'elle autorise des flux d'information légitimes qui seraient interdits par une application directe de la politique de Bell-LaPadula. Mais elle est tout aussi efficace, puisqu'on peut montrer qu'elle interdit bien tous les flux d'information illégitime.

Un prototype de serveur d'autorisation et de noyau de sécurité a été réalisé sur un système réparti composé de micro-ordinateurs avec le système à micro-noyaux Chorus. Une démonstration, mettant en oeuvre un système de messagerie multi-niveau a été développée et est aujourd'hui opérationnelle.

Un autre schéma d'autorisation est en cours de développement qui concerne cette fois la préservation de l'intégrité d'un système orienté objet, et en particulier adresse le problème de la coexistence de logiciels de criticité différente. En effet, dans la plupart des applications coexistent des fonctions critiques (par exemple le pilotage d'un avion) et des fonctions non-critiques (par exemple la gestion de la vidéo des passagers). Dans la mesure où les fonctions non-critiques peuvent perturber (en monopolisant les ressources) ou contaminer (par propagation d'erreurs) les fonctions critiques, la solution industrielle actuelle consiste à appliquer aux logiciels non-critiques les méthodes de développement et de vérification exigées pour les logiciels critiques (normes ou standards propres à chaque domaine d'application tel que l'avionique, le nucléaire, le ferroviaire...). On peut envisager au contraire d'autoriser la coexistence de logiciels validés à des niveaux différents, en utilisant des mécanismes de protection adéquats.

C'est ce que propose notre politique multi-niveau inspirée de la politique de Biba et adaptée à un environnement objet. Chaque objet du système se voit associer un niveau d'intégrité (en relation étroite avec le degré de criticité de ce dernier, et par conséquent avec son niveau de validation) qui caractérise la confiance qu'on porte en son comportement. Notre schéma d'autorisation permet le contrôle des flux d'informations entre les différents objets du système, le but étant d'éviter toute propagation d'erreurs d'un objet de faible intégrité vers un objet de plus haute intégrité.

La solution proposée permet de garantir une souplesse plus grande d'utilisation que celle de Biba grâce à l'introduction de différents types d'objets additionnels dans le système. En effet, on compte d'une part des objets mono-niveaux qui obéissent aux règles strictes de Biba, mais également des objets multi-niveaux et des objets dits de validation. Les objets multi-niveaux ont la propriété de pouvoir parcourir plusieurs niveaux sans pour autant autoriser des flux illégaux, ce qui en rend l'utilisation plus souple (bien que des règles de validation propres doivent leur être appliquées). Les objets de validation utilisent des mécanismes de tolérance aux fautes permettant la remontée d'informations de faible niveau d'intégrité vers des niveaux de plus haute intégrité (leur rôle étant en fait de faire monter la confiance que l'on porte aux données au niveau nécessaire); ce flux normalement interdit est un apport essentiel à ce type de politique, proposant une solution au problème classique de la dégradation du niveau des informations.



previous up next top index Précédent : Architectures à métaobjets et tolérance Suivant : Evaluation quantitative de la sécurité Remonter : Action de recherche