Précédent : Architectures à métaobjets et tolérance
Remonter : Action de recherche Suivant : Evaluation
quantitative de la 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.