Frédéric Cuppens et Nora Cuppens-Boulahia

(1)

Les modèles de sécurité

Fr´ed´eric Cuppens et Nora Cuppens-Boulahia

Abstract

L’objectif des modèles de sécurité est de donner une expression des besoins de sécurité des systèmes d’informations (SI). Depuis le début des années 70, de très nombreux modèles ont été proposés. Nous nous intéressons, dans ce chapitre, à trois catégories de modèles : les modèles de contrôle d’accès, de flux et d’usage. Comme les utilisateurs d’un SI n’ont pas tous les mêmes droits d’accès aux informations gérées par le SI, l’objectif d’un modèle de contrôle d’accès est d’exprimer une politique d’autorisation. Les limites des modèles de contrôle d’accès sont connues ; ils ne prennent pas en compte les attaques que peuvent réaliser les applications piégées par Chevaux de Troie. Des modèles de contrôle de flux ont donc été définis pour traiter ce problème. Plus récemment, pour prendre en compte les nouveaux besoins de sécurité présent dans certaines applications telles que la gestion des droits électroniques (DRM), des modèles de contrôle d’usage ont été proposés. Dans tous les cas, un modèle de sécurité doit inclure la possibilité d’exprimer une politique d’administration qui spécifie qui peut gérer et mettre à jour la politique de sécurité.

1 Introduction

Le début des années 70 a vu la définition des premiers modèles de sécurité : modèle de contrôle d’accès [30] et de contrôle de flux [5]. Depuis, de nombreux modèles de sécurité ont été définis.

L’objectif de ce chapitre est de faire le point sur les principaux travaux menés sur ce sujet au cours des trente dernières années.

Dans ce chapitre, nous ne considèrons pas les modèles con¸cus pour analyser les protocoles de sécurité, en particulier les protocoles cryptographiques. Ces modèles (voir par exemple [?]) ont

été proposés pour analyser des propriétés telles que l’authentification, la non répudation ou la fraicheur d’une information.

Dans ce chapitre, nous nous intéressons d’abord aux modèles de contrôle d’accès proposés pour modéliser des politiques d’autorisation. Dans ce contexte, l’un des premiers modèles proposés fut celui de Harrison, Ruzzo et Ullman (HRU, voir [26]). HRU a deux composantes : un modèle de contrôle d’accès et un modèle d’administration. Le modèle de contrôle d’accès repose sur l’identité des entités, d’où le nom de I-BAC (Identity Based Access Control) pour désigner cette partie du modèle HRU. L’administration est ditediscrétionnaire, d’où le nom de modèle discrétionnaire (ou DAC, Discretionary Access Control) que l’on a tendance à utiliser pour désigner l’ensemble du modèle HRU.

Plusieurs limites sont apparues à l’usage du modèle I-BAC. En particulier, le manque de structuration de ce modèle rend complexe l’expression et la gestion d’une politique d’autorisation. De nombreux autres modèles ont ensuite été proposés. Ces modèles ont introduit de nombreux concepts pour davantage structurer l’expression de la politique d’autorisation : rôles, tâches, vues,

´equipes. Le mod`eles Or-BAC (Organization Based Access Control, voir [29]) permet de structurer l’expression de la politique d’autorisation en utilisant l’ensemble de ces concepts.

Des modèles à base de règles (Rule-BAC voir par exemple [27, 8] ont été proposés pour exprimer des politiques d’autorisation incluant des règles de contrôles d’accès dynamiques. L’expression de ce besoin dans le modèle Or-BAC est également possible grâce à l’introduction du concept de contexte.

Les premiers modèles de contrôle d’accès ne permettaient que d’exprimer des autorisations positives ou permissions. Les modèles plus récents offrent également la possibilité d’exprimer des

(2)

autorisations négatives ou interdictions. Ces modèles facilitent l’expression de règles de contrôles d’accès présentant desexceptionsmais posent le problème de la gestion des conflits entre permissions et interdictions. Nous examinerons, dans la section 2.8, les principales stratégies de résolution de conflits qui ont été proposées dans la littérature.

On sait depuis la définition du modèle de Bell et LaPadula [5] que les modèles de contrôle d’accès ne permettent pas de prende en compte le problème des applications piégées, encore appelées Cheval de Troie. Bell et LaPadula ont ainsi défini le premier modèle de contrôle deflux(ou de type MAC, Mandatory Access Control). Cependant, ce premier modèle ne résoud pas tous les problèmes, en particulier la possibilité pour un Cheval de Troie de transmettre illégalement des informations via uncanal caché. Le modèle de non-interférence [24] permet de traiter ce problème mais conduit à un cloisonnement strict du à l’hypothèse extrême que toutes les applications peuvent être piégées par un Cheval de Troie. Dans la pratique, le modèle de Non Interférence s’avère difficilement applicable. Des modèles plus récents permettant d’assouplir les hypothèses trop pessimistes du modèle de non interférence ont ainsi été proposés. Nous présenterons en particulier dans ce chapitre les modèles de Bell et LaPadula étendu [4], DTE [?] et causalité [10].

Tous ces modèles de sécurité doivent inclure un modèled’administration pour exprimer qui peut définir et mettre à jour une politique d’autorisation représentée dans ces modèles. Le premier modèle d’administration est le modèle de type discrétionnaire proposé par HRU [26]. Ce premier modèle permet d’administrer une politique d’autorisation exprimée dans le modèle I-BAC.

De très nombreux autres modèles d’administration discrétionnaire ont ensuite été proposés et le modèle TAM (Typed Access Matrix, voir [?]) est peut-être le plus abouti dans ce domaine. Mais, l’expression d’une politique d’administration dans ces modèles restent limitée. Plus récemment, de nouveaux modèles adaptés aux modèles RBAC (Role Based Access Control) ou Or-BAC ont

été définis. Ces modèles sont auto-administrés, c’est-à-dire la politique d’administration s’exprime en utilisant les mêmes concepts que ceux utilisés pour exprimer la politique d’autorisation. Nous verrons également comment exprimer les besoins d’administration dans les modèles de contrôle de flux de type MAC en contrôlant la déclassification.

Enfin, dans les nouvelles applications plus ouvertes ne reposant plus nécessairement sur une architecture client-serveur, les modèles de contrôle d’accès ou de contrôle de flux ne sont plus complètement adaptés. De nouveaux modèles voient le jour pour répondre aux besoins de contrôle d’usage(voir par exemple, le modèle ABC [?]). Ces modèles ne limitent plus la politique de sécurité

`a l’expression de permissions et d’interdictions mais introduisent ´egalement le conceptd’obligation.

Ces nouveaux modèles devraient, par exemple, être mis en œuvre dans les applications de gestion des droits électroniques (DRM) ou les services web.

Le plan de ce chapitre est le suivant. Les sections 2 et 3 sont respectivement consacrées aux modèles de contrôle d’accès et de contrôle de flux. La section 4 s’intéresse aux modèles d’administration.

Enfin, la section 5 propose une synthèse et ouvre des perspectives sur les nouveaux modèles de contrôle d’usage.

2 Contrˆ ole d’acc` es

2.1 Mod` ele I-BAC

Nous désignons par I-BAC (Identity Based Access Control) le premier modèle de contrôle d’accès proposé dans la littérature (voir [30]). Ce modèle introduit les concepts fondamentaux de sujet, d’action et d’objet :

• Le sujet est l’entité active du SI. Il désigne le plus souvent un utilisateur ou une application s’exécutant pour le compte d’un utilisateur.

• L’objet est l’entité passive du SI. Il désigne une information ou une ressource à laquelle un sujet peut accéder pour réaliser une action.

(3)

• L’action désigne l’effet recherché lorsqu’un sujet accède à un objet. On peut par exemple désirer lire ou mettre à jour l’information contenue dans un objet ou bien recopier le contenu d’un objet dans un autre objet.

L’objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets via l’utilisation des actions. Ce contrôle est basé sur l’identité du sujet et l’identificateur de l’objet, ce principe de contrôle d’accès donnant son nom au modèle I-BAC.

Le modèle I-BAC introduit ensuite le concept de politique d’autorisation. Dans I-BAC, une politique d’autorisation correspond à l’expression d’un ensemble d’autorisations positives (ou permissions) ayant le format suivant : un sujet a la permission de réaliser une action sur un objet.

La possibilité de spécifier dans un modèle de contrôle d’accès des autorisations négatives (ou interdictions) ne sera offerte que beaucoup plus récemment. Nous examinons les modèles offrant cette possibilité dans la section 2.8.

En fait, dans I-BAC, on suppose implicitement que la politique de contrôle d’accès est fermée, c’est-à-dire par défaut tous les accès sont interdits. La politique d’autorisation spécifie donc des permissions et on refusera l’accès si la politique d’autorisation ne permet pas de dériver que l’accès est explicitement permis.

Pour représenter une politique d’autorisation, le modèle proposé dans [30] introduit également un autre concept fondamental, celui de matrice de contrôle d’accès qui sera ensuite repris dans plusieurs autres modèles (voir par exemple [26]). Dans une matrice de contrôle d’accès, les lignes et colonnes de la matrice correspondent respectivement à l’ensemble des sujets et des objets du SI.

Les “cases” de la matrice représentent l’ensemble des permissions qu’un sujet donné possèdent sur un objet donné.

Le modèle de type I-BAC est aujourd’hui implanté dans la plupart des systèmes d’exploitation actuels, tels que Windows, Unix ou Linux. Pour mettre en œuvre un tel modèle dans un SI, on n’implante pas directement la matrice de contrôle d’accès. Il existe en fait deux grandes approches possibles suivant que l’implantation repose sur une décomposition en lignes ou en colonnes de la matrice.

La décomposition en colonnes consiste à associer, à chaque objet, un descripteur appeléliste de contrôle d’accès, qui représente l’ensemble des sujets ayant des accès sur l’objet considéré avec, pour chaque sujet, l’ensemble des actions que ce sujet peut réaliser sur cet objet.

La décomposition en ligne consiste à associer à chaque sujet, un ensemble decapacités, représentant l’ensemble des objets auxquels le sujet peut accéder avec, pour chaque objet, l’ensemble des actions que le sujet peut réaliser sur cet objet.

A l’usage, une limite importante du modèle I-BAC est apparue : la politique d’autorisation devient rapidement complexe à exprimer et administrer. Il est en effet nécessaire d’énumérer les autorisations pour chaque sujet, action et objet. En particulier, lorsqu’un nouveau sujet ou objet est créé, il est nécessaire de mettre à jour la politique d’autorisation pour définir les nouvelles permissions associées à ce sujet ou objet.

Pour pallier ce problème, des modèles ont plus récemment été définis. Tous ces modèles ont en commun de proposer une expression plus structurée de la politique d’autorisation. Nous présentons dans les sections suivantes, les modèles proposant respectivement une structuration des sujets, des actions et des objets.

2.2 Mod` ele R-BAC

Le modèle RBAC (Role Based Access Control, voir [34]) propose de structurer l’expression de la politique d’autorisation autour du concept de rôle. Un rôle est un concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction de ces utilisateurs joue dans l’organisation.

Le principe de base du modèle R-BAC est de considérer que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles re¸coivent donc des autorisations de réaliser des actions

(4)

sur des objets. Comme I-BAC, le modèle R-BAC ne considère que des autorisations positives (permissions) et fait donc l’hypothèse que la politique est fermée.

Un autre concept introduit par le modèle R-BAC est celui desession. Pour pouvoir réaliser une action sur un objet, un utilisateur doit d’abord créer une session et, dans cette session, activer un rôle qui a re¸cu l’autorisation de réaliser cette action sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce rôle activé.

Lorsqu’un nouveau sujet est créé dans le SI, il suffit d’affecter des rôles à ce sujet pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet ensemble de rôles. Comparé au modèle I-BAC, la gestion de la politique d’autorisation s’en trouve simplifiée puisqu’il n’est plus nécessaire de mettre à jour cette politique chaque fois qu’un nouveau sujet est créé.

Dans le cas général, n’importe quel ensemble de rôles peut être affecté à un utilisateur et un utilisateur peut activer dans une session n’importe quel sous-ensemble des rôles qui lui ont été affectés.

Le modèle R-BAC introduit la notion de contrainte pour spécifier des politiques d’autorisation incluant des situations plus restrictives. Ainsi, une contrainte de séparationstatique spécifie que certains rôles, par exemple médecin et infirmier, ne peuvent pas être simultanément affectés à un utilisateur. Une contrainte de séparationdynamiquespécifie que, même si certains rôles peuvent être affectés à un utilisateur, par exemple médecin libéral et chirurgien, ces rôles ne peuvent pas être activés simultanément dans une même session.

Dans R-BAC, il est également possible d’organiser les rôles de fa¸conhiérarchique. Les rôles héritent les autorisations des autres rôles qui lui sont hiérarchiquement inférieurs. Lorsqu’un rôle r1 est hiérarchiquement supérieur à un rôler2, on dit quer1 est un rôleseniorder2.

Le mod`ele R-BAC constitue aujourd’hui un standard [21]. De nombreux SI mettent en œuvre ce standard, par exemple Unix Solaris `a partir de la version 8 ou l’API Authorization Manager RBAC de Windows Server 2003.

2.3 Mod` ele T-BAC

Dans les modèles I-BAC et R-BAC, les actions correspondent généralement à des commandes

élémentaires, comme la lecture du contenu d’un objet ou l’écriture dans un objet.

Dans les applications récentes, le besoin apparaˆıt de contrôler la réalisation d’actions composites, appelées tâches ou activités. Par exemple, dans une agence de voyage, la tâche d’achat d’un billet d’avion se décompose en plusieurs actions plus élémentaires telles que la réservation du billet, le paiement du billet et l’édition d’une facture. Le besoin de contrôle sur des activités composites est en particulier présent dans les applications de typeworkflow[3].

Le modèle T-BAC (Task Based Access Control, voir [36]) fut le premier modèle à introduire le concept de tâche. D’autres modèles ont ensuite été développés pour contrôler l’exécution des activités dans un workflow (voir [9, 39]). En particulier, l’utilisateur ne doit obtenir une permission que lorsque c’est nécessaire pour poursuivre l’exécution de l’activité considérée (“just in time”

permission). Ainsi, dans l’exemple d’achat d’un billet d’avion, la permission d’éditer une facture ne doit être activée qu’après la réservation et l’achat du billet.

2.4 Mod` ele V-BAC

Les modèles R-BAC et T-BAC ont respectivement introduit les concepts de rôle et de tâche pour structurer les sujets et les actions. Pour faciliter l’expression et la gestion d’une politique d’autorisation, nous avons également besoin d’un concept pour structurer les objets.

Parmi les modèles de contrôle d’accès proposant une telle structuration des objets, on peut citer le modèle de sécurité proposé par SQL pour les bases de données relationnelles. L’expression d’une politique de sécurité en SQL repose sur le concept de vue. Nous désignerons donc par V-BAC (View Based Access Control) ce type de modèle de contrôle d’accès.

Intuitivement, dans une base de données relationnelle, une vue correspond au résultat d’une requête SQL auquel on a donné un nom. Ce concept de vue est ensuite utilisé pour structurer l’expression

(5)

d’une politique d’autorisation à l’aide des instructions GRANT (qui permet d’accorder une nouvelle permission à un utilisateur) et REVOKE (qui permet de supprimer une permission que possédait un utilisateur). Une vue constitue donc un moyen efficace pour accorder un accès à l’ensemble des objets contenus dans la vue. A noter que ces objets sont parfois virtuels dans la mesure où une vue SQL n’est pas matérialisée.

SQL/3 [31], qui correspond à la dernière évolution de la norme SQL, propose d’étendre le modèle V-BAC en combinant les concepts de vue et de rôle pour structurer les objets et les sujets. On peut ainsi définir le modèle VR-BAC.

Le concept de vue ne se limite pas au modèle relationnel. On pourrait aussi l’utiliser dans un système d’exploitation. Actuellement, la plupart des systèmes d’exploitation ne proposent que le concept de répertoire pour structurer l’expression de la politique d’autorisation. En utilisant le concept de vue, on pourrait par exemple définir une vue contenant l’ensemble des objets ayant pour suffixe .doc et appartenant au répertoire /pierre/projet1 et utiliser cette vue dans l’expression de la politique d’autorisation du système d’exploitation. Dans ce cas, une syntaxe reposant sur XPath pourrait être proposée pour exprimer la politique d’autorisation. C’est déjà l’approche utilisée pour spécifier une politique d’autorisation pour documents XML (voir par exemple [7, 23]).

2.5 Mod` ele T-MAC

Dans les applications récentes, il est souvent nécessaire de considérer plusieurs organisations simul- tanément. Par exemple, dans les applications de services web, un utilisateur d’une certaine organisation peut souhaiter accéder aux données appartenant à une autre organisation. Une organisation est une entité structurée. Par exemple, un hôpital correspond à une organisation qui se décompose en plusieurs sous-organisations : les différents départements de l’hôpital, les différents services de ces départements, etc. Chaque organisation gère en général sa propre politique d’autorisation.

Certaines organisations peuvent également être créées dynamiquement en fonction des activités que doit prendre en charge l’hôpital. Par exemple, une équipe de soin peut être créée pour prendre en charge un patient particulier. Cette organisation pourra ensuite être dissoute une fois les activités réalisées.

Remarquons que les autorisations d’un sujet d´ependent non seulement du rˆole du sujet mais

également de l’organisation dans laquelle ce sujet exerce son rôle. Ce problème a été identifié dans le modèle T-MAC.

Le modèle T-MAC (Team Based Access Control, voir [37]) introduit la notion d’équipe. Dans T-MAC, des autorisations sont associées aux rôles ainsi qu’aux équipes. Les autorisations que possède un sujet résultent de la combinaison des autorisations associées aux rôles exercés par le sujet et des autorisations associées à l’équipe à laquelle est affecté le sujet. Plusieurs combinaisons (par exemple, l’union des autorisations) sont envisagées.

En fait, le modèle T-MAC est incorrect car il introduit deux relations binaires : rôle-autorisation et équipe-autorisation. Si l’on introduit la notion d’équipe, il est en fait nécessaire de considérer une relation ternaire équipe-rôle-autorisation pour spécifier que les autorisations dépendent non seulement du rôle mais aussi de l’équipe dans laquelle est exercée ce rôle. A l’aide d’une telle relation ternaire, on pourra ainsi facilement spécifier que les autorisations du rôle médecin change suivant qu’il s’agit d’un médecin dans une équipe de garde ou d’un médecin dans une équipe d’urgence.

Cette imperfection du modèle T-MAC a été corrigée dans le modèle Or-BAC, que nous allons présenté maintenant.

2.6 Mod` ele Or-BAC

Le modèle Or-BAC (Organization Based Access Control, voir [29]) reprend les concepts de rôle, d’activité, de vue et d’organisation introduites respectivement dans les modèles R-BAC, T-BAC, V-BAC et T-MAC. Dans Or-BAC, l’expression d’une politique d’autorisation est centrée sur le

(6)

concept d’organisation (contrairement à R-BAC où la politique d’autorisation est centrée sur le concept de rôle).

Les concepts de rôles, de vues et d’activités sont des concepts organisationnels. Chaque organisation définit ainsi les rôles, les activités et les vues dont elle souhaite réglementer l’accès en appliquant une politique d’autorisation. Le modèle Or-BAC introduit donc trois relations relevant-role, relevant-activity et relevant-view pour spécifier respectivement les rôles, les activités et les vues gérés par l’organisation.

Ensuite, chaque organisation spécifie les affectations des sujets aux rôles en utilisant la relation ternaireempower. On peut remarquer que cette modélisation permet, par exemple, de considérer qu’un même sujet est affecté à des rôles différents suivant l’organisation considérée. De fa¸con similaire, deux autres relations ternaires consideret use permettent de respectivement spécifier, pour chaque organisation, les relations entre action et activité d’une part, et entre objet et vue d’autre part.

Le modèle Or-BAC offre également la possibilité de spécifier desrole-definition,view-definitionet activity-definition. Une role-definition est une condition logique qui, si elle est satisfaite, permet de conclure qu’un sujet se trouve automatiquement affecté au rôle correspondant à la role-definition.

De fa¸con similaire, une view-definition et une activity-definition correspondent à des conditions logiques pour gérer respectivement les vues et les activités.

Une politique d’autorisation s’exprime en spécifiant, pour chaque organisation considérée, les ac- tivités que les rôles ont la permission de réaliser sur les vues. La politique d’autorisation s’exprime donc de fa¸con complètement indépendante des ensembles de sujets, actions et objets gérés par le SI. On parle ainsi de politique d’autorisationorganisationnelle.

Le modèle propose une règle de passage pour dériver automatiquement, d’une politique d’autorisation organisationnelle, les permissions concrètes s’appliquant aux sujets, actions et objets. Cette règle spécifie que, dans une organisation donnée, si un sujet est affecté à un certain rôle, un objet est utilisé dans une certaine vue, une action implante une certaine activité et si la politique d’autorisation de cette organisation spécifie que ce rôle a la permission de réaliser cette activité sur cette vue, alors on peut dériver que ce sujet a la permission de réaliser cette action sur cet objet.

Dans Or-BAC, on peut également définir des hiérarchies de rôles (comme dans R-BAC), mais aussi d’activités, de vues et d’organisations. Chacune de ces hiérarchies est associée à un mécanisme d’héritage des permissions (voir [16] pour plus de détail). La définition de ces hiérarchies permet une expression plus modulaire de la politique d’autorisation organisationnelle.

2.7 Mod` eles d’autorisations dynamiques et contextuelles

Dans la pratique, de nombreuses autorisations ne sont pas statiques mais d´ependent de conditions qui, si elles sont satisfaites, permettent d’activer dynamiquement les autorisations. Dans ce cas, on parle souvent d’autorisations contextuelles.

Ainsi, les autorisations peuvent dépendre de contextes temporels (par exemple permission pen- dant les heures de travail), contextes géographiques (par exemple, permission à l’intérieur de l’enceinte sécurisée de l’entreprise), de contextes provisionnels (permission si d’autres actions ont au préalablement été réalisées comme dans le cas d’un workflow). D’autres types de contextes peuvent être également être définis (voir [20] pour une proposition de taxonomie).

Pour représenter ces autorisations contextuelles, plusieurs modèles de contrôle d’accès à base de règles ont été proposés (modèles de type Rule-BAC, voir [27, 8]). Dans ces modèles, une politique d’autorisation correspond à un enesemble de règles de la forme condition → permission qui spécifient qu’une permission peut être dérivée lorsqu’une certaine condition est satisfaite.

Les modèles de type Rule-BAC repose sur la logique du premier ordre qui est, dans le cas général, indécidable. Face à ce problème, la plupart de ces modèles propose d’utiliser Datalog pour avoir une procédure de décision en temps polynomial à condition que les règles respectent certaines restrictions syntaxiques (voir [38] pour plus de détail).

Comparés aux modèles présentés dans les sections précédentes, les modèles Rule-BAC présentent une expressivité plus grande, utile pour spécifier des autorisations contextuelles. En contrepar-

(7)

Permission

Consider Activity

Role

Empower Organization

View

Use Abstract level

Object Subject

Action

Is_permitted Concrete level

Context

Figure 1: Structure du mod`ele Or-BAC

tie, on perd malheureusement la structuration de la politique d’autorisation que permettaient l’introduction des concepts de rˆole, d’activit´e, de vue et d’organisation.

Le modèle Or-BAC offre également la possibilité d’exprimer des autorisations contextuelles. Pour cela, le concept decontexteest explicitement introduit dans le modèle. La définition d’un contexte correspond à une condition logique qui permet de conclure que l’on se trouve dans le contexte lorsque cette condition est satisfaite. Remarquons que chaque organisation définit ses contextes ce qui permet de modéliser que la définition d’un contexte tel queheure de travail peut varier d’une organisation à une autre.

En fait, dans la section 2.6, nous avons volontairement simplifié l’expression d’une politique d’autorisation organisationnelle en Or-BAC. Dans le cas général, une autorisation spécifie qu’un rôle a la permission de réaliser une activité sur une vue dans uncontexteparticulier. La règle de passage pour dériver les permissions concrètes s’appliquant aux sujets, actions et objets est aussi légèrement plus coomplexe que celle présentée dans la section 2.6 puisqu’une permission ne doit être activée que lorsque la condition contextuelle correspondante est satisfaite (voir [20]).

Pour conclure cette section, remarquons qu’Or-BAC impose les mêmes contraintes syntaxiques que celle imposée par Datalog de manière à conserver une procédure de décision calculable en temps polynomial même lorsque l’on considère des autorisations contextuelles. Le modèle Or-BAC offre donc une expressivité comparable à celle des autres modèles de type Rule-BAC tout en proposant une expression très structurée de la politique d’autorisation.

2.8 Mod` eles d’autorisations positives et n´ egatives

Initialement, les modèles de contrôle d’accès ne permettaient que d’exprimer des autorisations positives (permissions). Récemment, des modèles offrant également la possibilité d’exprimer des autorisations négatives (interdictions) ont été proposés [6, 27, 9].

Combiner des autorisations positives et n´egatives dans une politique d’autorisation est int´eressant pour plusieurs raisons :

• Certaines politiques d’autorisation sont plus faciles à décrire en terme d’interdictions que de permissions. Par exemple, considérer une règle spécifiant que l’accès à une certaine vidéo est interdite aux personnes de moins de 12 ans.

(8)

• Lorsque la politique d’autorisation doit être mise à jour, il est parfois plus simple d’insérer une interdiction que de supprimer une permission existante.

• La combinaison des permissions et interdictions constitue un moyen simple pour exprimer des règles présentant des exceptions. Par exemple, on peut considérer les règles suivantes : (1) Les infirmiers ont l’interdiction d’accéder au dossier médical des patients, mais (2) En situation d’urgence, les infirmiers ont la permission d’accéder au dossier médical du patient concerné par l’urgence. Dans ce cas, la règle (2) doit être interprétée comme une exception de la règle (1).

Dans la suite, on dira que la politique d’autorisation estmixtelorsqu’elle inclut des autorisations positives et négatives. Remarquons que dans une politique d’autorisation mixte, on peut faire l’hypothèse que la politique est ouverteou fermée. Une politique ouverte considère qu’un accès est accepté si la politique d’autorisation ne permet pas de dériver que l’accès est explicitement interdit. Il s’agit donc de l’hypothèse inverse de la politique fermée déjà introduite dans la section 2.1.

Un nouveau problème apparait lorsque l’on considère des politiques d’autorisation mixtes : celui de la gestion des conflits entre les autorisations positives et négatives. En effet, pour un sujet, une action et un objet donnés, il est possible que la politique d’autorisation permette de dériver que l’accès est à la fois permis et interdit.

Pour résoudre ces situations de conflits, plusieurs stratégies ont été proposées dans la littérature.

Certaines approches (voir par exemple [27]) ne considèrent que des stratégies simples, telles que les interdictions l’emportent toujours sur les permissions, ou les permissions l’emportent toujours sur les interdictions. Ces stratégies ne conviennent pas pour traiter le problème des exceptions.

En effet, si une interdiction agit comme exception à une permission, alors cette interdiction doit l’emporter sur cette permission. Mais, dans le cas contraire, c’est-à-dire si une permission agit comme exception à une interdiction, alors c’est la permission qui doit l’emporter sur l’interdiction.

Pour rendre compte de stratégies plus élaborées permettant de gérer les exceptions, plusieurs modèles [6, 19] ont proposé d’introduire des priorités entre les règles de la politique d’autorisation.

La plupart des pare-feux donnent des exemples représentifs de mise en œuvre de ce type de stratégies. En effet, on peut interpréter les règles de filtrage d’un pare-feu comme un ensemble d’autorisations positives (dans le cas où la décision de la règle de filtrage est d’accepter le paquet) ou négatives (dans le cas où la décision est de rejeter le paquet). La priorité entre règles de filtrage correspond en général à l’ordre dans lequel les règles ont été écrites. Ainsi, lorsque plusieurs règles s’appliquent sur un même paquet, la décision finale correspond à celle de la première règle applicable (stratégie dite du “first matching”).

L’ordonnancement des règles constitue donc un moyen simple, mais efficace pour résoudre les conflits dans une politique d’autorisation mixte. Cependant, cette ordonnancement rend la politique d’autorisation plus complexe à exprimer et à mettre à jour. En effet, d’autres problèmes peuvent apparaˆıtre : le masquage (shadowing) et la redondance. L’anomalie de masquage apparaˆıt lorsqu’une règle devient inapplicable car des règles plus prioritaires seront systématiquement ap- pliquées avant elle. L’anomalie de redondance existe lorsqu’une règle peut être supprimé sans que cela change la politique d’autorisation. Par exemple, si l’on considère les deux règles suivantes : (1) L’accès à la vidéoV est interdite aux personnes de moins de 12 ans, (1) L’accès à la vidéo V est interdite aux personnes de moins de 16 ans. Alors la règle (1) est redondante.

Détecter ces anomalies dans une politique d’autorisation est important car (1) elles sont souvent révélatrices d’erreur dans l’expression de la politique d’autorisation, (2) même si elles ne correspondent pas à des erreurs, l’élimination de ces anomalies permet de réduire le nombre de règles de la politique d’autorisation.

Dans le cas des pare-feux, [2] propose un algorithme pour détecter certaines anomalies dans un ensemble de règles de filtrage. Cet algorithme n’étant malheureusement pas complet, un autre algorithme permettant de détecter et éliminer toutes les anomalies a ensuite été proposé dans [15].

(9)

3 Contrˆ ole de flux

Pour bien comprendre l’intérêt des modèles de contrôle de flux, il faut d’abord revenir sur le concept de sujet introduit dans la section 2.1. Nous avons indiqué qu’un sujet correspondait à un utilisateur ou une application s’exécutant pour le compte d’un utilisateur.

Dans le cas d’un utilisateur, on suppose que celui-ci peut essayer de violer la politique d’autorisation en accèdant illégalement à des objets. Mais s’il obtient légalement une information, on suppose

également qu’il ne va pas volontairement transmettre cette information à un autre utilisateur qui n’aurait pas le droit de connaˆıtre cette information. Par exemple, on suppose qu’un médecin ne va pas volontairement transmettre le contenu du dossier médical d’un de ses patients à une personne non autorisée. Il faut naturellement que l’organisation mette en place des procédures pour que cette hypothèse soit justifiée (par exemple habilitation, serment d’Hippocrate mais aussi sensibilisation des utilisateurs aux risques informatiques).

En revanche, on ne peut pas toujours faire les mêmes hypothèses si le sujet est une application s’exécutant pour le compte d’un utilisateur. En effet, certaines applications peuvent être piégées.

On parle alors de Cheval de Troie. Un Cheval de Troie peut avoir divers objectifs malveillants visant à porter atteinte à la confidentialité, l’intégrité ou bien la disponibilité des informations du SI. Dans le cas de la confidentialité, l’objectif de l’application est d’accéder à des informations et de volontairement transmettre ces informations vers un utilisateur qui n’a pas la permission d’y accéder. Cet utilisateur est le bénéficiaire du piège ; il peut s’agir par exemple du concepteur de l’application, d’un agent chargé de sa maintenance ou d’un utilisateur qui a réussi à remplacer l’application légitime par une application piègée.

Pour illustrer ce problème, considérons un médecin qui utilise son SI pour consulter les dossiers médicaux de ses patients. Supposons également que ce médecin puisse utiliser son SI pour consulter un dictionnaire médical via Internet et que ce médecin utilise une seule application pour à la fois consulter les dossiers médicaux et accéder au dictionnaire médical. Si cette application est piégée, alors il est possible que cette application utilise la connexion Internet pour transmettre, à l’insu du médecin, des informations contenues dans les dossiers médicaux.

Les modèles de contrôle d’accès présentés dans la section 2 ne permettent pas d’empêcher les actions malveillantes d’une telle application piégée. En effet, cette dernière peut réaliser son attaque sans violer la politique d’autorisation : elle consulte légitimement les dossiers médicaux et ensuite utilise l’accès Internet qui permet d’accéder au dictionnaire médical pour transmettre les dossiers médicaux vers le bénéficiaire du piège. Cela ne veut pas dire que ces modèles de contrôle d’accès sont inutiles. Mais, si l’on veut empêcher les attaques par Chevaux de Troie, il faut seulement utiliser ces modèles pour définir la politique d’autorisation des utilisateurs et des applications de confiance, c’est-à-dire des applications que l’on peut garantir sans piège.

Pour contrôler l’exécution des applications qui ne sont pas de confiance, d’autres modèles, appelés modèles de contrôle de flux (ou MAC, Mandatory Access Control), ont été définis. L’objectif de ces modèles est précisément d’assurer le confinement des applications pour empêcher les attaques par Chevaux de Troie. Comme plusieurs modèles de type MAC pour la confidentialité ont été définis, nous présentons ici les principaux : modèle de Bell et LaPadula, Non Interférence, Bell et LaPadula étendu et Causalité. Nous présentons ensuite les modèles de type MAC pour l’intégrité.

Les modèles de contrôle de flux pour la confidentialité et l’intégrité sont complémentaires : ils doivent être combinés pour garantir ces deux propriétés de sécurité dans le SI.

3.1 Mod` ele de Bell et LaPadula

Le modèle de Bell et LaPadula [5] fut le premier modèle de type MAC proposé. L’objectif de ce modèle est de définir des contraintes pour contrôler l’exécution des applications de manière à empêcher les attaques par Chevaux de Troie contre la confidentialité.

Le modèle de Bell et LaPadula considère des politiques de sécurité de type MAC particulière, dite politique de sécuritémulti-niveaux. Dans ce type de politique d’autorisation, on introduit un ensemble partiellement ordonné de niveaux de sécurité, par exemple Non-classifié (NC), Confidentiel

(10)

Z3 Z2 Z1

L4 L3

L1 L2

Figure 2: Passage d’une politique de type I-BAC vers une politique de type MAC

(C) et Secret (S). Tous les utilisateurs doivent avoir re¸cu un tel niveau de sécurité pour pouvoir accéder au SI ; il s’agit du niveau d’habilitation de l’utilisateur. On affecte également un niveau de sécurité à tous les objets gérés par le SI ; il s’agit du niveau de classificationde l’utilisateur.

La politique d’autorisation associée aux utilisateurs est simple : un utilisateur n’a la permission de lire un objet que si son niveau d’habilitation est supérieur ou égal au niveau de classification de l’objet lu. Sinon, l’utilisateur a l’interdiction de lire cet objet. On appelle habituellement cette condition “No Read Up”.

En revanche, on suppose que les applications peuvent être piégées. Une application travaille pour le compte d’un utilisateur. Le niveau d’exécution, encore appelé niveaucourant, d’une application est choisi par l’utilisateur mais doit être inférieur ou égal au niveau d’habilitation de cet utilisateur.

Pour empêcher une application de lire des objets interdits, on impose qu’une application ne peut lire un objet que si son niveau courant est supérieur au niveau de classification de l’objet. On appelle également cette condition “No Read Up”. Comme le niveau courant d’une application est toujours inférieur ou égal au niveau d’habilitation de l’utilisateur exécutant l’application, la condition de “No Read Up” sur les applications implique la condition de “No Read Up” sur les utilisateurs.

Mais, dans le modèle de Bell et LaPadula, on souhaite également empêcher qu’un Cheval de Troie puisse transmettre le contenu d’un objet lu vers un utilisateur uqui aurait l’interdiction de lire cet objet. Dans ce modèle, on suppose que le Cheval de Troie effectuera cette transmission illégale en recopiant le contenu de l’objet lu dans un autre objet que u pourra lire. Pour ˆınterdire ce flux illégal, on impose qu’une application ne peut écrire dans un objet que si le niveau courant de l’application estinférieurou égal au niveau de classification de l’objet. On appelle cette condition

“No Write Down” ou propriété “étoile”.

Le but unique de la condition de “No Write Down” est d’empêcher un Cheval de Troie de réaliser une attaque contre la confidentialité. Elle n’empêche pas une attaque contre l’intégrité au cours de laquelle une application tenterait de modifier illégalement des objets. Ce n’est pas l’objectif du modèle de Bell et LaPadula d’empêcher ce type d’attaque. Des modèles ont été définis pour cela (voir section ??).

Le passage d’une politique d’autorisation de type I-BAC vers une politique multi-niveaux de type MAC est toujours possible. A titre d’exemple, considérons le schéma de la figure 2. Z1, Z2 et Z3 sont trois ensembles d’objets et l’on suppose queZ1∩Z26=∅, Z1∩Z3 =∅et Z3⊂Z2. On suppose que le système est utilisé par quatre utilisateurs s1,s2,s3 ets4. Supposons par exemple, que dans une politique d’autorisation de type I-BAC, Z1 est l’ensemble des objets accessibles en lecture par s1, Z2 est celui accessible en lecture par s2 et Z3 celui accessible par s3 et s4 (on suppose ques3 ets4 ont les mêmes droits d’accès en lecture).

Dans ce cas, on introduit quatre niveaux de sécurité L1,L2,L3 etL4, avecL3 < L2, L4 < L1 et L4 < L2. s1 est habilité au niveauL1,s2 au niveau L2 et, s3 ets4 au niveauL3. Les objets re¸coivent les classifications suivantes :

• Objets deZ1−Z2 class´esL1

(11)

• Objets deZ2−(Z1∪Z3) class´esL2

• Objets deZ3 class´esL3

• Objets deZ1∩Z2 class´esL4

Soit par exemple une application exécutée par s1 au niveau L1. Ce programme pourra lire l’ensemble des objets de Z1. En revanche, il ne pourra pas écrire dans Z1 ∩Z2 pour éviter un éventuel flux verss2 (dans l’hypothèse où le programme serait piégé).

On peut remarquer que le passage I-BAC à MAC est faisable mais peut générer dans la pratique un grand nombre de niveaux.

3.2 Mod` ele de Non Interf´ erence

Dès la définition de leur modèle, Bell et LaPadula avaient observé que celui-ci ne permettait de contrôler que les Chevaux de Troie qui essayent de transmettre illégalement des informations par recopie dans un fichier. D’autres moyens de transmettre illégalement des informations existent que peut exploiter un Cheval de Troie. Ces moyens sont connus sous le nom decanaux cachés.

La principe général d’un canal caché consiste à transmettre des informations de fa¸con codée sous forme de 0 et de 1 en “frappant aux murs”.

Traditionnellement, on distingue deux types de canaux cachés : canaux cachés de stockage et canaux temporels. Un canal de stockage utilise une ressource non protégée du système (par exemple, en bloquant/débloquant l’accès à un registre) pour transmettre des informations. Un canal temporel exploite une ressource temporelle (par exemple, en faisant varier l’exécution d’une application).

Plusieurs modèles de contrôle de flux ont été proposés pour prendre en compte les canaux cachés [32, 35, 28]. Le plus connu est le modèle de non interférence [24, 25, 22]. Ce modèle permet de renforcer le modèle de Bell et LaPadula en empêchant les attaques des Chevaux de Troie contre la confidentialité, même via des canaux cachés de stockage. En revanche, le modèle de non-interférence ne contrôle pas les canaux cachés temporels.

Le principe du modèle est le suivant. SoientA1etA2deux applications s’exécutant respectivement aux niveauxL1etL2. SiL1=L2, alorsA1etA2peuvent s’échanger des informations. SiL1> L2, alors le flux d’informations deA2 vers A1 est autorisé. En revanche, tout flux de A1 versA2 est interdit. Enfin siL1 etL2ne sont pas comparables, aucun flux entreA1 etA2 n’est autorisé.

Plusieurs formalisations du principe de non interférence ont été proposées. On présente ici celle de Goguen et Meseguer [24]. SoitSI un système d’information. Ce SI permet aux utilisateurs d’exécuter des applications. SoitSeq(SI) l’exécution d’une certaine séquence d’applications dans SI. Chaque application est exécutée avec un certain niveau de sécurité. SiLest un certain niveau de sécurité, on définitP urge(Seq(SI), L), l’exécution obtenue en supprimant de Seq(SI) toutes les applications qui n’ont pas été exécutées avec un niveau inférieur ou égal àL.

Enfin, au cours de l’exécution d’une séquence d’applications, un utilisateur s obtient certains résultats (outputs) fournis par le SI. Les résultats obtenus par s au cours de l’exécution d’une séquenceSeq(SI) est notéeOutput(s, Seq(SI)).

On dit alors que le système satisfait la propriété de non interférence si pour toute séquenceSeqet pour tout utilisateurs, on a :

Output(s, Seq(SI)) =Output(s, P urge(Seq(SI), L))

où L représente le niveau d’habilitation du sujet s. Intuitivement, cette condition exprime que, pour un utilisateur ayant un niveau d’habilitationL, tout se passe comme si seules des applications de niveau inférieur àLavaient été exécutées dans le système.

La propriété de non-interférence est difficile à vérifier dans la pratique car elle concerne l’exécution d’une séquence d’applications. Des conditions suffisantes, dite de “unwinding” plus simples ont

été proposées [24, 25] pour vérifier qu’une application particulière vérifie la condition de non- interférence. Plus récemment, les travaux de Smith et Volpano [40] basés sur la théorie des types

(12)

permettent de vérifier que le code source d’un programme est non interférent. Ces travaux peuvent être appliqués à l’analyse statique de codes mais les conditions à vérifier sont pessimistes : l’exécution de certains programmes peut ne pas être interférente alors que ces programmes seront rejetés par l’analyse statique.

3.3 Mod` ele de Bell et LaPadula ´ etendu

La principale limite de la non-interférence est que cette condition est très restrictive à mettre en œuvre¹. Dans la pratique, elle a été uniquement appliquée avec succès sur de petits systèmes, par exemple des logiciels embarqués à bord de carte à puce. Toutes les autres tentatives d’appliquer la non interférence à des systèmes plus importants tels que des systèmes d’exploitation ou des systèmes de gestion de bases de données n’ont pas abouti à des solutions commercialisables car les solutions développées se sont avérées trop contraignantes à utiliser.

Pour de tels systèmes, le besoin de modèles de sécurité plus flexibles est évident. Pourquoi ? Parce que la non-interférence adopte le point de vue extrême que tous les programmes sont potentielle- ment malveillants et peuvent contenir un Cheval de Troie cherchant à transmettre illégalement des informations. Une telle hyptohèse n’est pas réaliste dans la pratique. Plus précisément, elle rend impossible la spécification de certaines fonctionnalités nécessaires dans la plupart des systèmes, par exemple des fonctions de chiffrement ou de déclassification. En effet, ces fonctions ont pour objectif de produire en sortie des résultats qui auront un niveau de classification strictement inférieur au niveau de classification des données fournies en entrées de ces fonctions.

Un modèle plus réaliste est le modèle de Bell et LaPadula étendu proposé dans [4]. Au lieu d’associer un niveau courant à chaque application, ce modèle associe un intervalle de niveaux [L1, L2] avecL1≤L2. Une application peut ainsi lire tout objet dont la classification est inférieure

àL2 et écrire dans tout objet de classification supérieure àL1. Ceci permet la déclassification.

Si l’on soup¸conne une application de pouvoir contenir un Cheval de Troie, alors il faut imposer queL1=L2. L’exécution de l’application est alors contrôlée par les mêmes conditions de sécurité que le modèle de Bell et LaPadula strict.

En revanche, siL16=L2, alors l’application ne doit pas contenir de Cheval de Troie. On dit alors que l’application est de “confiance”. Une fonction de déclassification peut ainsi être implantée par une application de confiance.

Il faut empêcher qu’une application qui contient un Cheval de Troie puisse appeler une application de confiance, par exemple une fonction de déclassification, pour transmettre illégalement des informations interdites. Pour cela, il faut imposer une condition pour contrôler l’invocation d’une application par une autre application : siA etA⁰ sont deux application associées respectivement aux intervalles [L1, L2] et [L⁰₁, L⁰₂], alorsApeut invoquerA⁰ si et seulement siL1≤L⁰₁etL⁰₂≤L2. Ainsi, une application qui n’est pas de confiance (c’est-à-dire telle queL1 =L2) ne peut jamais invoquer un application de confiance (c’est-à-dire telle queL⁰₁6=L⁰₂).

Le modèle de Bell et LaPadula étendu est proche du modèle actuellement mis en œuvre dans OLS (Oracle Label Security) ??, le module implantant une politique de sécurité multi-niveaux sous Oracle à partir de la version 8i. Ce modèle est beaucoup plus flexible à mettre en œuvre que les modèles de Bell et LaPadula strict et de Non Interférence.

On peut cependant remarquer que le modèle de Bell et LaPadula étendu présente la limite suivante : il est impossible de modéliser une application réalisant certains transferts d’informations entre deux niveauxL1 etL2qui ne sont pas comparables. En effet, on ne peut pas considérer une application Atravaillant sur [L1, L2] car [L1, L2] n’est pas un intervalle siL1 etL2 ne sont pas comparables.

3.4 Mod` ele de Causalit´ e

L’intérêt du modèle de Bell et LaPadula étendu est qu’il est plus souple que Non Interférence. Mais il présente aussi un inconvénient car, comme le modèle de Bell et LaPadula strict, il ne permet pas

1La mˆeme remarque est valable pour le mod`ele de Bell et LaPadula.

(13)

de contrˆoler les canaux cach´es.

Le modèle de causalité [10, 11] est un modèle de contrôle de flux basé sur l’analyse des dépendances causales qui contrôle les canaux cachés (y compris temporels) et qui est plus souple à mettre en œuvre que Non Interférence. A chaque sujets, on associe un ensemble d’objets que s a le droit d’observer notéDroit(s). On associe également àsun ensembleObs(s) qui représente l’ensemble des observations quesà réaliser sur le système.

La propriété de causalité est satisfaite siObs(s) dépend causalement deDroit(s) (voir [10] pour plus de détails). En fonction des objets qui sont inclus dans l’ensembleDroit(s), il est possible de définir plusieurs politiques de contrôle de flux différentes :

1. Causalité sur les inputs [10]. Dans ce cas, on suppose que seules les données introduites par les utilisateurs sont de confiance. Toutes les données produites en exécutant des applications dans le système ne sont pas de confiance car elles peuvent avoir été calculées par un programme contenant un Cheval de Troie.

On suppose donc queDroit(s) ={In(s⁰)|niv(s⁰)≤niv(s)}

c’est-à-diresa le droit d’observer toutes les données introduites par les autres sujetss⁰ayant un niveau d’habilitation inférieur ou égal às.

Causalité sur les inputs est une propriété que l’on peut comparer à Non Interférence. Causalité sur les inputs présente plusieurs avantages (voir [11]). En particulier, le modèle permet de considérer qu’une même donnée est introduite par un sujet à plusieurs niveaux de sécurité différents. Cette possibilité permet de prendre en compte une opération de déclassification gérée à l’extérieure du SI, chose impossible avec Non Interférence.

2. Causalité étendue. Il est possible d’ajouter àDroit(s) des données produites par une application de confiance (par exemple, le résultat d’une opération de déclassification).

3. Possibilité d’exprimer des politiques d’autorisation de type Muraille de Chine [14]. Dans ce type de politique d’autorisation [13], il est possible d’accéder séparément à certaines données mais ces données ne peuvent pas être agrégées à cause de conflits d’intérêt entre les sources ayant émis ces données. Pour modéliser ce type de politique d’autorisation avec Causalité, il faut considérer que l’ensemble des droits d’un sujet évolue au cours du temps.

4. Possibilité de contrôler l’évolution dynamique des niveaux de classification d’un objet ou le niveau courant associé à une application [12].

3.5 Mod` ele de Biba

La définition usuelle du contrôle d’accès obligatoire spécifie que les restrictions sur le flux des informations se font indépendamment des actions de l’utilisateur. Bien que cette définition fait souvent référence au modèle de Bell et LaPadula, plusieurs systèmes mettent en place ce type de contrôle pour garantir des propriétés d’intégrité (banques, hopitaux, etc.).

Le premier modèle traitant de la protection de l’intégrité est celui de Biba ?? appelé également Bell et LaPadula à l’envers (Bell and LaPadula upside down). En effet, Biba a constaté que la confidentialité et l’intégrité sont des concepts duals. La confidentialité est une contrainte sur qui est permis de lire la donnée alors que l’intégrité est une contrainte sur qui a le droit de l’écrire ou de la modifier. Ainsi, dans le modèle de Bell et LaPadula, l’information ne peut pas circuler vers les niveaux inférieur pour éviter la fuite de données sensibles. Inversement, dans le modèle de Biba, les informations ne peuvent migrer vers des hauts niveaux d’intégrite sinon les donnéespiégées(virus, cheval de troie, etc.) en provenance de niveaux d’intégrité faibles contamineraient les données sainesde niveaux d’intégrité supérieures. Formulées autrement, ces contraintes correspondraient à des propriétés duales à celles de Bell et LaPadula, ”No Write Up” et ”No Read Down”. Cependant, le modèle de Biba n’empêche pas l’action d’un Cheval de Troie mais permet de confiner son effet

à certains niveaux d’intégrité. C’est une conséquence du No Write Up : le Cheval de Troie ne

(14)

pourra pas attaquer les données ayant un niveau d’intégrité supérieur au niveau où le Cheval de Troie a été installé. En ce sens, modèle proche de la Sand Box de Java. De plus, pas de possibilité pour l’attaquant de piloter le Cheval de Troie à distance grâce auNo Read Down.

Bien entendu, La dualité avec le modèle de Bell et LaPadula fait que le modèle de Biba souffre

également du problème soulevé par Maclean [?] et discuté dans la section BLPE concernant le principe de tranquilité. Pour éviter ce problème de statisme des labels, une solution adoptée dans les systèmes assurant des propriétés d’intégrité sur la base du modèle de Biba est l’utilisation d’une politique de type Low Water Mark dans laquelle le label d’intégrité d’un objet est affecté au niveau le plus bas en lecture par le processus qui l’a créé. C’est la cas dans LOMAC [?], une version étendue de Linux, qui utilise cette approche pour gérer les problèmes des programmes pièges provenant du réseau public. Bien entendu, cette implantation ne peut stopper un virus infectant le niveau d’intégrité faible de se multiplier et d’envoyer ses clônes vers le réseau public.

3.6 Mod` ele Boebert&Kaine et DTE

Boebert et Kain ont introduit une implantation du modèle de non-interférence, type enforcement (TE), mise en oeuvre dans le système Lock??, et qui a évoluée plus tard vers le modèle DTE. Ce modèle est basé sur un moniteur de référence composé d’une unité de gestion de la mémoire (MMU) qui contrôle les privilèges conventionnels de lecture, écriture, etc. et un composant de gestion des objets labélisés (TOP) qui est en charge de la protection de l’état du système. Le TOP initialise les tables de définition des privilèges que contrôle le MMU. Des attributs de sécurité sont associés aux sujets et aux objets et le TOP doit effectuer les comparaisons adéquates entre ces attributs de sécurité pour établir des droits d’accès conformément à la politique de sécurité envisagée dans le MMU. Dans ce modèle, les attributs de sécurité associées aux sujets et aux objets sont de trois types :

• lelabel de confidentialit´eest associ´e aux sujets et aux objets,

• l’identité de l’utilisateurinitiant la fonction, est associée aux sujet l’exécutant. Le deuxième attribut de sécurité qui lui est équivalent pour les objets est une liste de contrôle d’accès (ACL) associés aux objets. elle est constituée des identités des utilisateurs possédant des permissions d’accès aux contenus des objets ainsi que le nombre maximum d’accès autorisés pour chaque couple (utilisateur, pivilège),

• le domaine d’exécution du sujet est associé au sujet et correspond à l’encodage du sous- système dont il fait partie. Pour les objets, le troisième attribut de sécurité est le type de l’objet et il correspond au format de l’information contenue dans l’objet en question.

La détermination des droits d’accès à attribuer à un sujet donné pour avoir accès à un objet donné se base sur les trois attributs de sécurité cités ci-avant. Ainsi, pour la mise en oeuvre de la politique d’accès obligatoire, le TOP effectue une comparaison entre les niveaux de sécurité des sujets et des objets. Ensuite, il calcule un ensemble initial de droits d’accès conformément à l’algorithme défini dans la section 3.

Pour la mise en oeuvre de la politique d’accès discrétionnaire, le TOP vérifie par la suite la liste de contrôle d’accès (ACL) des objets. Lorsqu’une entrée dans l’ACL correspond à la partie utilisateur du contexte de sécurité du sujet, elle est comparée avec les droits d’accès définis dans l’ensemble initial qui traduit la politique d’accès obligatoire. Tout droit d’accès dans cet ensemble initial qui n’apparaˆıt pas dans l’ACL est supprimé. On obtient donc un nouvel ensemble de droits d’accès.

Enfin, la troisième étape de détermination des droits d’accès se base sur une comparaison du domaine du sujet et du type de l’objet auquel il veut avoir accès. Chaque sujet est considéré comme également un objet et donc, son second attribut de sécurité est une liste de types d’objets accessibles par le domaine du sujet et le nombre d’accès maximal permis à chacun de ces types. En fait, l’agrégation de ces listes de définition de domaines constitue la table DDT (Domain Definition Table). Ainsi, le TOP, pour effectuer le contrôle domaine-type, il consulte les lignes de la DDT

(15)

pour retrouver le domaine du sujet concerné par cette vérification, puis repère le type de l’objet dont il est question et ensuite compare le résultat de cette entrée identifiée avec l’ensemble de droits d’accès intermédiaire calculé auparavant. Tout droit apparaissant dans cet ensemble et qui n’est pas défini dans la DDT est supprimé. Le résultat est l’ensemble final des droits d’accès qui est transmis au MMU.

Cependant, il y a lieu de tenir compte également des changements au niveau des domaines qui peuvent se produire suite à un effet de bord d’un appel de procédures. Si la procédure en question ne peut être exécutée dans le domaine de l’appelant, soit l’appel est illégal ou alors un chagement de domaine est nécessaire pour le satisfaire. Ce type d’information sur les possibilités de changer de domaine sont enregistrés dans une autre table DTT (Domaine Transition Table). Lorsqu’un appel nécessite un changement de domaine, le moniteur de référence suspend le sujet appelant et active le sujet appelé avec son contexte de sécurité le temps de

Ainsi, le modèle TE, traite le problème de l’intégrité en s’orientant plutôt vers l’isolation de l’action plutôt que de l’utilisateur. En d’autres termes, les domaines sont utilisés pour astreindre les actions

à s’exécuter uniquement dans une seule enclave et d’une seule fa¸con ; si l’accès n’est pas autorisé

à ce domaine, l’action ne peut être exécutée. Cette approche permet de prévenir des accès non autorisés à travers des chemins non conventionnels. On peut reconnaˆıtre derrière cette approche, une structure très utilisée dans la conception de systèmes sécurisés réels : les pipelines. Un aspect non traité bien qu’important dans des modèles de politique de sécurité à niveaux hiérarchisés, comme Bell et LaPadula (aspect maquillé sous la dénomination de ”applications de confiance”) et dans ceux plus orientés intégrité comme le modèle de Biba.

Le modèle TE traduit les états possibles de non-interférence par la définition de la DDT et les transitions d’états par la DTT. L’intégrité est alors assurée par un contrôle strict de ces tables, ce qui semble être un objectif raisonnablement accessible bien que le stockage et la gestion d’un grand nombre de tables peut être complexe. Ce modèle offre également une grande flexibilité.

Pour pouvoir effectuer certaines actions préalablement définies selon un critère de tâche, d’équipe, de groupe ou encore de rôle, l’utilisateur doit avoir accès au bon domaine. D’autres restrictions d’accès à des programmes ou les fichiers accessibles dans ce domaine à cet utilisateur peuvent être adjointes sinon le système deviendrait assez rapidement difficile à gérer.

Avant de refermer cette section, il est important de signaler que DTE n’est qu’une extension du modèle TE. Les principales différences sont : les matrices d’expression de la politique de sécurité ont disparu au profit d’un langage de politique de sécurité intuitif, l’utilisation d’une hiérarchie de labels de sécurité à la Bell et LaPadula ou Biba n’est pas exigée et des possibilités de transitions entre domaines de fa¸con automatique est rendue possible. Ce modèle a été mise en oeuvre dans le système d’exploitation SELinux??, mais avec l’apport d’autres mécanismes basés sur les modèles RBAC et IBAC. Dans SELinux, des exigences d’implantation ont nécessité l’abandon du concept de domaine au profit de type pour faciliter l’expression de la politique d’accès et permettre des intéractions entre objets.

4 Administration

L’administration consiste en la création et la maintenance des éléments constituant la politique de sécurité tels que les utilisateurs, les actions, les objets, les rôles, les labels de sécurité, les droits, etc.

La spécification de la politique de sécurité et sa mise à jour sont les deux tâches les plus importantes d’administration. Elle est différente selon le modèle de sécurité adopté (contrôle d’accès, contrôle de flux, etc.) pour définir la politique à mettre en oeuvre. Elle peut être centralisée ou distribuée selon la flexibilité du modèle. Les modèles d’administration ne sont pas nombreux (voir figure

??) et s’explique par l’intérêt faible qui leur a été porté. La complexité des tâches attribuer aux administrateur de sécurité et la multiplication des brèches de sécurité résultant d’une mauvaise gestion plutôt que d’un mauvais modèle de sécurité font que les travaux récents [?] en matière de contrôle d’accès, de flux et d’usage prêtent une attention particulière à la définition des modèles d’administration de la sécurité.

(16)

4.1 Mod` ele DAC

L’administration du modèle Id-BAC est souvent de type discrétionnaire. Elle repose sur la notion de propriétaire : chaque objet a un propriétaire qui décide quels sont les sujets qui ont accès à cet objet. Il est souvent le créateur de l’objet et dispose de tous les droits sur cet objet. Ce plein contrôle dont le propriétaire dispose sur ses ressources, lui donne aussi la possibilité de déléguer à un autre sujet le droit d’accorder des droits sur certaines d’entre-elles.

Le plus célèbre modèle discrétionnaire est le modèle HRU qui a été défini en 1976 par Harrison, Ruzzo et Ullman []. C’est un modèle matriciel défini à partir d’un ensemble de sujets, d’un ensemble d’objets et d’un ensemble fini de règles. Ces règles décrivent dans quelles conditions on peut modifier le contenu de la matrice d’accès. Les primitives de ces règles sont les suivantes:

• donner un droit r `a un sujet s sur un objet o

• cr´eer un sujet s

• cr´eer un objet o

• enlever un droit r `a un sujet s sur un objet o

• d´etruire un sujet s

• d´etruire un objet o (possible si ce n’est pas un sujet)

La matrice d’accès est con¸cue telle que les colonnes correspondent aux droits exercés sur un objet tandis que les lignes correspondent aux droits que possèdent un sujet. La mise en œuvre de ce modèle est coûteuse en mémoire lorsque le nombre des utilisateurs est important. La constitution de groupes d’utilisateur peut être envisagée afin de limiter la taille de la matrice. Cependant la constitution et la maintenance de ces groupes sont délicates, car un sujet peut appartenir à plusieurs groupes. Le modèle HRU a néanmoins l’avantage d’être simple à décrire et permet une modélisation simple de plusieurs systèmes de protection. Il offre la possibilité de vérifier qu’il n’y a pas d’ajout aléatoire de droits dans la matrice d’accès. On peut ainsi analyser les problèmes de sûreté et de sécurité.

En général, les modèles DAC sont assez statiques car une fois que la matrice d’accès est en place, sa modification peut être complexe si elle est grande. Ils ont néanmoins l’avantage d’avoir une politique décentralisée.

4.2 Mod` ele TAM

Le modèle HRU a été con¸cu pour étudier le problème de sûreté. Le problème de sûreté consiste à savoir si on peut créer ou non un droit qui n’existait pas auparavant suite à une exécution d’une séquence de commandes. Un système de contrôle d’accès est dit sûr si on ne peut pas créer un nouveau droit dans ces conditions. Il se trouve que dans le modèle HRU tel qui a été défini, le problème de sûreté est indécidable.

Il existe cependant des cas particuliers du modèle HRU pour lesquels on peut décider de la sûreté du système. Plusieurs chercheurs ont proposé des modèles pour résoudre ce problème de sûreté:

Jones, Lipton, Snyder, Denning en proposant le modèle ”Take-Grant” en 79 [?], Ravi S. Sandhu dans les années 80 avec SPM (schematic protection model)[?] puis dans les années 90 avec le modèle TAM [?].

Les primitives utilisées dans le modèle TAM sont identiques à celles de HRU mais les sujets et les objets sont typés. Ces types et les droits ne sont pas prédéfinis dans le modèle, ce qui permet une politique de sécurité plus flexible. L’une des premières modifications du modèle TAM afin d’obtenir un problème décidable est que le système est monotone, c’est à dire qu’il ne possède pas de requête de destruction ou de suppression. Pour obtenir un système monotone on se limite donc à trois primitives (celles pour donner un droit, créer un objet ou un sujet). On obtient alors le modèle