Précédent : Logiciels Remonter : PROJET SATURNE, Système réparti tolérant Suivant : Actions industrielles
Précédent : Logiciels
Remonter : PROJET SATURNE, Système réparti
tolérant Suivant : Actions industrielles
Participants : Jean-Charles Fabre , Marc-Olivier Killijian
, Arnaud Ladrech , Gregory Lajon , Tanguy Perennou , Juan-Carlos
Ruiz-Garcia , Tanja Van Achteren
Mots-clés : Tolérance aux fautes, sécurité,
réflexivité, protocole à métaobjet
Résumé : Une architecture à métaobjets pour systèmes tolérant les fautes a été conçue et réalisée. Les propriétés et les performances d'un tel système ont pu être évaluées sur une application de test et le résultat global est très positif. L'approche a permis de concevoir de façon claire selon une méthode de conception par objet des mécanismes de tolérance aux fautes et aux intrusions qui soient réutilisables, spécialisables en fonction de conditions opérationnelles et composables en fonction des besoins de l'application.
Le modèle d'architecture de système basé sur une utilisation
récursive des métaobjets défini précédemment à été enrichi et
validé expérimentalement sur une application répartie de type
bancaire. Les prototypes actuels acceptent des applications
réparties plus complexes que celles initialement développées
(invocations imbriquées multi-serveurs). Bien que l'héritage ne
puisse être pris en compte au niveau des objets de base, compte
tenu du protocole à métaobjet simple utilisé, les objets de
l'application peuvent être attachés à des métaobjets implémentant
différentes stratégies de tolérance aux fautes avec ou sans
mécanisme de sécurité. L'invocation asynchrone de méthode a été
aussi implémentée. L'expérimentation de cette nouvelle
architecture a été effectuée sur un réseau de stations Unix avec
le protocole à métaobjet d'Open C++ v1. Nous avons pu constater
la souplesse d'intégration procurée par cette approche, en
premier lieu l'indépendance entre la programmation de
l'application et la programmation des mécanismes utilisés. Ces
prototypes sont, à notre connaissance, les premiers systèmes
orientés-objets réflexifs tolérant les fautes et les intrusions.
L'un des résultats essentiels est d'avoir pu déterminer les
limites de cette approche, en particulier celles dues au
protocole à métaobjet utilisé et à certaines conventions de
programmation. Il est aussi apparu que la distribution (au sens
de la gestion de groupe) était difficile à séparer des mécanismes
de tolérance aux fautes répartis. Les métaobjets de tolérance aux
fautes nécessitent des données communes avec la gestion de groupe
et doivent pouvoir effectuer des contrôles sur le traitement des
messages. D'autre part, il est clair que des informations d'état
existant au métaniveau sont parfois nécessaires lors de la phase
de reconfiguration (clonage). L'utilisation récursive de
métaobjet pose aussi le problème de l'accès au niveau de base par
tous les métaobjets de niveau supérieur. Les performances du
système ont pu être mesurées et ont montré que l'interaction
objet-métaobjet était négligeable par rapport aux fonctionnalités
de tolérance aux fautes proprement dite (coût des communications
de groupe par exemple) [3].
La conception des mécanismes de tolérance aux fautes a été effectuée en utilisant la méthode de développement orienté-objet BON et a permis de définir une hiérarchie de classes (au sens de l'héritage) en vue de leur réutilisation. Une première hiérarchie de mécanismes de tolérance aux fautes a été définie : elle a montré que l'on pouvait factoriser ces mécanismes et donc favoriser la réutilisation de classes de base et leur spécialisation. C'est ainsi que certaines classes de base, telles que celles responsables de la reconfiguration et du clonage, ont été réutilisées pour la conception et la mise en oeuvre d'un mécanisme de réplication et de vote majoritaire (vote à la destination)[5].
Enfin, de premières investigations sur l'utilisation de
support d'exécution répartis d'objets, tel que COOL-ORB (au
standard CORBA) et l'intégration d'un protocole à métaobjet dans
ce type de support ont été engagées. Elle repose sur
l'utilisation d'un compilateur d'Open C++ qui permet de définir
un protocole à métaobjet très fin. Ce protocole se compose d'une
fonction de capture des interactions compatible avec des objets
CORBA et d'une fonction de capture d'état basée sur la
réflexivité à la compilation. Différentes approches de capture
d'état à l'exécution ont été définies et leur évaluation est en
cours. A terme, ce protocole permettra de concevoir une
architecture réflexive de système tolérant les fautes
accidentelles et intentionnelles au standard CORBA. Différents
langages cibles sont envisagés, en particulier Java. Des
expérimentations seront menées sur une nouvelle plate-forme
Chorus composée d'un réseau local de 10 PC-pentium et du système
de développement Chorus ClassiX. Elles reposeront sur COOL-ORB et
sur l'utilisation de deux types de systèmes de communication de
groupe, l'un sur réseau local type système embarqué et l'autre
orienté grand réseau. Enfin, un effort sur la validation de
telles architectures sera engagé pour évaluer l'intérêt de ce
type d'approche de ce point de vue. Au delà des collaborations au
sein du projet DeVa (cf. ![[*]](../icons/cross_ref_motif.gif){kind=icon}
), nous collaborons sur ce sujet
avec le Professeur S. Chiba, concepteur d'Open C++, à
l'Université de Tsukuba au Japon .
Participants : Jean-Charles Fabre , Jean Arlat , Manuel
Rodriguez-Moreno , Frédéric Salles
Mots-clés : Systèmes critiques, technologie
micronoyaux, validation, injection de faute
Résumé : Une première classification des comportements erronés d'un micronoyau du commerce, Chorus ClassiX en l'occurrence, a été effectuée. Au travers d'une première campagne d'injection, différents comportements erronés ont pu être observés. Enfin, une approche permettant de complémenter les mécanismes de détection internes du micronoyau a été définie; elle est basée sur une modélisation des fonctionnalités internes du noyau.
L'expérimentation menée sur les mécanismes de synchronisation a
été concluante. Le développement d'un outil d'injection
permettant de mener des campagnes d'injection de fautes plus
intensives a démarré. Nous avons voulu dans un premier temps
caractériser le comportement erroné d'un micronoyau et analyser
les conséquences possibles sur le système hôte. Trois catégories
d'expériences ont été menées :
Nous avons ainsi pu effectuer une classification préliminaire des comportements du micronoyau en présence de fautes, dont certains s'avèrent non acceptables pour les systèmes critiques visés. Ces résultats sont par ailleurs exploités afin de cibler les types de mécanismes de confinement d'erreur nécessaires. D'autre part, nous avons défini et expérimenté une approche permettant de confiner les erreurs (complémenter les mécanismes internes de détection d'erreur) en s'appuyant sur des modèles formels de certaines classes de fonctions du micronoyau. L'idée consiste à définir une API (interface de programmation) qui permette l'exécution des primitives de base mais qui effectue aussi une détection d'erreur. Cette approche a été expérimentée sur le module interne de synchronisation qui gère des sémaphores. Une expression formelle de ses propriétés a été définie. Elle contrôle l'utilisation des sémaphores d'un point de vue sémantique. Son implémentation nécessite un niveau d'observabilité permettent l'accès aux files de processus par exemple. Dans nos expériences, la couverture de détection est alors de 100% [9]. Cette approche doit être étendue à d'autres fonctions. Nous considérons actuellement, les classes du type gestion mémoire, communication et ordonnancement. C'est sur ce dernier aspect que porte actuellement nos efforts, ce qui constitue une des perspectives de recherche sur ce thème. Enfin, nous avons débuté le développement d'un environnement de validation de micronoyaux basé sur l'injection de faute (MAFALDA) pour caractériser de façon plus précise le comportement du micronoyau en présence de faute au travers de campagnes d'injection intensives. Le développement de MAFALDA et son utilisation pour valider l'interface de confinement d'erreur est la seconde orientation de nos travaux sur ce sujet.
Participants : Yves Deswarte , Jean-Charles Fabre , David
Powell , Eric Totel
Résumé : Les travaux récents de ce module portent essentiellement sur la définition d'une politique d'intégrité dont le rôle est d'empêcher la perturbation de logiciels critiques par des logiciels qui le sont moins. Cette définition s'est accompagnée de plusieurs implémentations, en particulier dans le cadre du projet européen GUARDS.
Notre politique multi-niveau est inspirée de la politique de Biba
[Bib97] et adaptée à un
environnement objet. Chaque objet du système se voit associer un
niveau d'intégrité 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é [16,15].
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. Cette solution est similaire à celle proposée dans la politique de Clark et Wilson [CW87].
La définition de cette politique a entraîné l'implémentation
du modèle selon de nombreux axes, que ce soit d'un point de vue
scientifique (afin de démontrer la faisabilité des mécanismes) ou
d'un point de vue industriel (dans le cadre du projet ESPRIT
GUARDS, cf. ).
La première implémentation a été réalisée sur une architecture répartie à objets CORBA. Un noyau d'intégrité distribué réalise tous les contrôles d'accès entre les objets relativement aux règles de notre politique. Cette implémentation, très proche du modèle orienté objet, a permis de montrer la validité du modèle.
D'autre part, l'analyse d'un système à micro-noyau CHORUS a permis de mettre en évidence l'ensemble des fonctionnalités qui doivent être modifiées pour implémenter notre politique dans un tel système. Le noyau d'intégrité est intégré dans le micro-noyau et a pour but de réaliser l'ensemble des contrôles de flux d'information entre objets. Pour ce faire, on doit isoler dans les sources du noyau toutes les primitives créant des flux entre les objets, et appliquer (grâce au noyau d'intégrité) les règles que nous avons définies à l'ensemble des flux.
Dans le cadre du projet ESPRIT GUARDS, la réalisation d'une bibliothèque de fonctions à la norme POSIX est également en cours, afin de définir une norme standard aux mécanismes d'intégrité.
Participants : Yves Deswarte , Rodolphe Ortalo
Mots-clés : sécurité, politique de sécurité, logique
déontique, systèmes d'information, évaluation quantitative
Résumé : Nos études récentes concernent la définition et l'expérimentation d'une méthode de spécification d'une politique de sécurité. Le langage que nous proposons, basé sur la logique déontique, permet une description rigoureuse mais aussi assez naturelle, particulièrement adaptée à la description des besoins de sécurité d'une organisation. Cette méthode a été expérimentée dans le cadre d'une agence bancaire de taille moyenne.
Les travaux relatifs à l'évaluation quantitative de la sécurité
ont été poursuivis dans l'optique d'étendre la méthodologie
développée originellement pour des systèmes informatiques en
direction des systèmes d'information en général. D'une part, un
langage de spécification des politiques de sécurité, utilisable
dans le cadre des organisations, a été proposé. Nous avons
développé une extension syntaxique du langage de la logique
déontique classique qui vise à faciliter la spécification d'une
politique de sécurité. Cette extension permet de structurer les
différents éléments de la spécification, d'utiliser des
représentations génériques (comme la notion de rôle [13] facilitant la définition et
l'évolution de la politique de sécurité, ainsi que d'utiliser
éventuellement une représentation graphique [12]. Afin d'expérimenter
l'ensemble de la méthode, une étude pratique a été menée dans une
organisation réelle présentant des besoins de sécurité. Il s'agit
d'une agence bancaire de taille moyenne (environ une trentaine de
personnes). Etant donné la multitude des opérations bancaires
susceptibles d'être mises en oeuvre dans une telle agence,
l'étude s'est concentrée sur un petit nombre d'opérations
intéressantes du point de vue de la sécurité, et pouvant
présenter certaines vulnérabilités. Il s'agit des opérations
d'attribution de crédit, qui font apparaître un mécanisme de
délégation des pouvoirs entre les employés au sein même de
l'agence, et des opérations anonymes sur les titres (titres au
porteurs) qui peuvent éventuellement donner lieu à des
malversations. Une spécification de la politique de sécurité de
cette organisation, centrée sur ces opérations, a été proposée en
suivant la méthode présentée précédemment. Cette spécification a
été complétée par une recherche sur le terrain des vulnérabilités
fournissant l'opportunité de mettre en défaut les objectifs de
sécurité, ce qui a conduit à la construction du graphe des
privilèges correspondant. Ce graphe a été exploité afin d'obtenir
une évaluation quantitative de la sécurité du système
d'information vis-à-vis de deux objectifs de sécurité, et de
comparer différentes propositions de modification du
fonctionnement de l'organisation.
Précédent : Logiciels
Remonter : PROJET SATURNE, Système réparti
tolérant Suivant : Actions industrielles