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 [11,17,19,18]. 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 : il est capable de répondre à des requêtes demandant à accéder à une méthode particulière d'un objet particulier mais aussi à des requêtes correspondant à des actions faisant intervenir plusieurs objets dans le système (par exemple, imprimer un fichier f sur une imprimante i). Cette souplesse permet une plus grande facilité d'administration du serveur d'autorisation. Sur chaque site du système, un noyau de sécurité est chargé de contrôler l'accès aux objets locaux. L'ensemble des noyaux de sécurité garantissent le respect de la politique de sécurité. Chacun de ses noyaux gère de facon autonome les droits d'accès aux objets temporaires et aux objets de fine granularité locaux. Il convient de préciser que ces noyaux de sécurité ne sont en aucun cas liés définitivement à une politique de sécurité particulière. Ils permettent de mettre en oeuvre des politiques de sécurité visant à préserver la confidentialité des informations aussi bien que des politiques de sécurité visant à préserver l'intégrité des informations.
Nous avons étudié ce schéma d'autorisation dans le cadre d'application d'une politique de sécurité multi-niveaux basée sur des contrôles obligatoires. Nous avons pour cela attribué des labels aux utilisateurs, aux objets et aux requêtes du système. En effet, le mode de communication dans un tel système est la communication par envoi de messages (requêtes) et ces requêtes véhiculent de l'information sensible ; il est donc nécessaire de les étiqueter par des labels au même titre que les objets et les utilisateurs du système. Nous avons attribué à chaque utilisateur un label représentant son habilitation. En ce qui concerne les objets, nous avons distingué deux familles d'objets que nous avons labellés différemment. Certains objets échangent des informations avec les requêtes qui y accèdent ; nous avons attribué à ces objets un label unique (représentant la classification de l'information qui constitue leur état). En revanche, il existe des objets pour lesquels il n'y a aucun flux d'information entre eux et les requêtes qui les accèdent. Ces objets utilisent des informations de la requête pour invoquer d'autres objets mais ne gardent aucune mémoire des ces informations et leur état est réinitialisé à chaque invocation. Nous avons attribué à ces objets une parenthèse de labels consituée de deux labels représentant l'intervalle de confiance que l'on estime pouvoir accorder à de tels objets. En effet, même si un objet sans état ne doit en principe garder aucune mémoire des informations contenues dans les requêtes qui y accèdent, il semble raisonnable de ne pas lui laisser forcément manipuler toutes les informations du système. Le label maximum que l'on affecte à un objet sans état signifie qu'il ne pourra pas lire des informations dont la classification dépasse ce label. Le label minimum permettra quant à lui d'empêcher un objet sans état d'écrire de l'information dont la classification est inférieure à ce label (ainsi un objet sans état possédant un cheval de Troie ne pourra produire qu'une fuite d'informations limitée). Enfin, nous avons attribué aux différentes requêtes une parenthèse de labels. La politique de sécurité garantie par les noyaux de sécurité est basée sur des règles qui, en fonction des labels des requêtes et des labels des objets auxquels ces requêtes accèdent, autorisent ou non les accès. Un prototype d'un tel noyau de sécurité est actuellement en réalisation sur le micro-noyau Chorus.