Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Modèles théoriques de contrôle d’accès
Avec le contrôle d’accès, on s’intéresse à garantir deux propriétés fondamentales : laconfidentia-litéet l’intégritédes informations contenues dans un SI.
Définition 2.1.1 (Confidentialité) Prévention des accès non autorisés à une information.
Définition 2.1.2 (Intégrité)Prévention des modifications non autorisées d’une information.
Afin de permettre l’implantation de politiques de confidentialité et d’intégrité en leur sein, les systèmes d’exploitation disposent de mécanismes de contrôle d’accès. Typiquement, ceux-ci fonc-tionnent sur le modèle suivant :
– Un sujet est une entité active du système (essentiellement les processus) ;
– Un objet est une entité passive, un conteneur d’information, sur lequel un sujet peut effectuer une action (les fichiers, sockets de communication, périphériques matériels. . . ) ;
– Une permission est une certaine action sur un objet. Une permission peut être accordée ou refusée (par exemple, lecture, écriture, exécution. . . ).
Le contrôle d’accès est configuré par un ensemble de règles spécifiant un sujet, un objet et des droits d’accès (cf. figure 2.1). Un cas particulier de règles (cf. figure 2.2) est celui spécifiant une action d’un sujet vers un autre sujet (envoi de signal ou de message inter-processus).
La manière naturelle de représenter les règles d’accès est sous forme matricielle, par unematrice d’accès. L’ensemble des sujets correspond aux lignes, et l’ensemble des objets aux colonnes. Dans chaque case de la matrice, on trouve un sous-ensemble des permissions.
Ainsi, une contrainte sur la confidentialité se traduira par le refus de la permission de lecture : par exemple, pour empêcher que le serveur Webapache n’accède au fichier contenant les mots de passe des utilisateurs, /etc/shadow, on ne lui autorise pas la lecture de celui-ci.
La notion de matrice d’accès a été introduite parLampson[ 1971]. Il propose de placer suivant les lignes l’ensemble D des domaines de protection (qui représentent des contextes d’exécution pour les programmes, i.e. les sujets), et en colonnes l’ensemble X des objets (qui inclut les domaines), dans la matrice A. Il pose ensuite deux définitions :
Définition 2.1.3 (Capabilities Lists) Étant donné un domaine d ∈ D, la liste des capacités (capabi-lities) pour le domaine d est l’ensemble des couples (o, A[d, o]), ∀o ∈ X.
Définition 2.1.4 (Access Control Lists) Étant donné un objet o ∈ X, la liste de contrôle d’accès (ACL) pour l’objet o est l’ensemble des couples (d, A[d, o]), ∀d ∈ D.
La définition 2.1.3 lie un domaine d avec les permissions A[d, o], de la matrice d’accès A, qu’il possède sur chaque objet o. La définition 2.1.4 lie un objet o avec les permissions A[d, o] que la matrice A accorde à chaque domaine d.
A noter que les notions de capability et d’ACL avaient déjà été définis de façon générale dans [Lampson 1969]. Dans [Lampson 1971], l’auteur raffine ces définitions en les liant a la notion de matrice d’accès.
Ensuite, il est nécessaire de pouvoir faire évoluer ces politiques de sécurité, afin par exemple de prendre en compte l’intégration de nouveaux utilisateurs et applications dans le système d’exploita-tion. Cette évolution doit être contrôlée pour prévenir les abus, ainsi que les configurations indésirables pour la politique. C’est pourquoi chaque mécanisme de contrôle d’accès définit des procédures de mo-dification des droits d’accès sur les objets du système. Elles sont plus ou moins restrictives suivant le but recherché, et requièrent éventuellement un accès de niveau administrateur.
Typiquement, sous Linux, ces procédures sont accomplies par les commandeschown et chmod. La première modifie le propriétaire d’un fichier ou dossier, et ne peut-être utilisées que parroot. La seconde modifie les droits d’accès sur un fichier ou dossier, et requiert que l’utilisateur en soit propriétaire. Par conséquent, pour modifier les droits d’accès d’un fichier appartenant à root, il est nécessaire d’utiliser le compteroot.
Enfin, la croissance des vulnérabilités liées aux interactions entre des systèmes d’informations distants a poussé de nouvelles études sur l’administration de politiques à grande échelle. Ainsi, la prise en compte de multiples sites logiques d’application (différents réseaux par exemple) ou de dif-férentes organisations amenées à coopérer sont les apports des recherches en matière depolitiques multi-domaines. Également, le support des équipements relevant de langages de politiques de sécurité différents est au cœur des études sur les modèles multi-politiques. Enfin, la complexité d’écriture de telles politiques de sécurité a conduit à la conception deméta-politiques. Nous aborderons ces points dans la partie 2.3.
Les parties suivantes présentent les différentes familles de modèles théoriques. On en distingue principalement trois :
Contrôle d’accès discrétionnaire La caractéristique principale du DAC ou Discretionary Access Control est le fait que ce sont les utilisateurs qui attribuent les permissions sur les ressources qu’ils possèdent. C’est le type de mécanisme utilisé principalement dans les systèmes d’exploi-tation modernes. En effet, il est très léger en termes d’administration, étant donné que l’attribu-tion des droits est faite par les utilisateurs et non pas par les administrateurs.
Contrôle d’accès obligatoire Contrairement au DAC, le MAC ou Mandatory Access Control délègue l’attribution des permissions à une entité tierce, typiquement un administrateur externe de la politique de sécurité. Ainsi, les utilisateurs du système ne peuvent pas intervenir dans l’attribu-tion des permissions d’accès, même s’ils disposent de droits d’administration dans le système d’exploitation.
Contrôle d’accès basé sur les rôles Le modèle RBAC pour Role-Based Access Control a pour but de simplifier l’administration des droits d’accès des utilisateurs individuels en fournissant un niveau d’indirection supplémentaire. Plutôt que de donner directement des permissions aux utilisateurs, on définira différents rôles possibles pour l’utilisation du système d’exploitation, avec des droits d’accès associés. Ensuite chaque utilisateur a accès à une liste de rôle, suivant son activité. Un seul rôle peut être actif à un moment donné.
DAC
Le contrôle d’accès discrétionnaire (DAC) est le modèle implanté dans la majorité des systèmes d’exploitation actuels (Microsoft Windows, Solaris, Linux, FreeBSD). Il doit son nom au fait que l’attribution des permissions d’accès se fait “à la discrétion” du propriétaire d’une ressource. Typi-quement, les droits d’accès sur un fichier sont positionnés par l’utilisateur déclaré comme propriétaire de ce fichier.
Les modèles théoriques deDAC que nous allons étudier maintenant sont HRU et TAM.
Modèle HRU
Établi par [ Harrison et al. 1976], le modèle HRU décrit les politiques de contrôle d’accès discré-tionnaires traditionnelles. Une matrice P représente l’ensemble des droits d’accès des sujets vers les objets. De plus, les sujets peuvent créer de nouveaux sujets ou objets, et ajouter des droits. HRU propose de modéliser la protection dans les systèmes d’exploitation comme suit : l’ensemble des sujets S et l’ensemble des objets O sont tous deux l’ensemble des entiers de 1 à k. R est l’ensemble des droits génériques (tels que possession, lecture, écriture, exécution). Le système d’exploitation contient un ensemble fini C de commandes α1, . . . , αn, qui représente toutes les opérations fournies par le système d’exploitation (création de fichier, modification des droits…). Du point de vue de la protection, les commandes de l’ensemble C ont toutes la même forme : elles prennent en paramètre des sujets et objets, et suivant la présence de certains droits dans la matriceP , elles effectuent un
ensemble d’actions élémentaires sur le système. Ces actions élémentaires sontenter: et delete pour l’ajout et la suppression de droits, create subject et create object pour la création de nouveaux sujets et objets et enfin destroy subject et destroy object pour la destruction de sujets et objets. La configuration du système de protection est le triplet (S, O, P ).
Pour étudier le problème de la sûreté d’un système de protection,HRU s’intéresse au transfert de droit, qui se produit lorsqu’une commande insère un droit particulier r dans la matrice P , dans une case ou il était précédemment absent. Par conséquent, étant donné une configuration initiale de la politique de sécurité, un système est considéré sûrsafe() pour un droit r si aucune des commandes ne provoque le transfert du droit r.
Les auteurs du modèle HRU ont prouvé que dans le cas d’un système de protectionmono-opérationnel, i.e. dans lequel toutes les commandes ne contiennent qu’une seule action élémentaire, le problème de savoir si ce système est sûrest décidable, toutefois l’algorithme de vérification est NP-complet. Or la seule commande de création de fichier d’un système d’exploitation de type UNIX se compose déjà de deux actions : création d’un nouvel objet, et positionnement des droits sur celui-ci. Les auteurs s’intéressent donc au problème dans le cas général, et prouvent que le problème de la sûreté d’un système de protection estindécidabledans le cas général.
En outre, les auteurs mentionnent le fait que la taille du problème est réduite à une taille polyno-miale dès lors que les actions de création de sujet ou d’objet sont retirées du système de protection.
Modèle TAM
Le modèle Typed Access Matrix (TAM), introduit par [Sandhu 1992], propose une extension du modèle HRU, en intégrant la notion de typage fort. Cette notion dérive de travaux plus anciens sur SPM (Sandhu’s Schematic Protection Model) par [Sandhu 1988], et se traduit par l’attachement de “types de sécurité” immuables à tous les sujets et objets du système d’exploitation.
Par rapport à la modélisation de HRU vue précédemment, il existe maintenant l’ensembleT des types de sécurité. Le point important est que cet ensemble est fini : la création de nouveaux types n’est pas possible. La gestion des types est prise en compte dans les opérations élémentaires décrites plus haut pour HRU.
Ensuite, Sandhu s’intéresse à la version monotone de TAM, soit MTAM (Monotonic Typed Access Matrix), obtenue en ôtant les opérations de suppression (droits, sujets ou objets). Il démontre que le problème de la sûreté est décidable dans le cas d’un modèle de protectionMTAM où le graphe de création des sujets et objets est acyclique. Toutefois la complexité de ce problème reste NP. C’est pourquoi Sandhu définit le modèle MTAM ternaire, dans lequel toutes les commandes ont au maximum trois arguments. Au prix d’une perte d’expressivité, le problème de sureté voit sa complexité ramenée à un degré polynomial.
MAC
L’un des grands avantages du DAC est que l’attribution des permissions d’accès est gérée di-rectement par les utilisateurs. Malheureusement, c’est aussi l’une de ses défaillances majeures. En effet, comme le résume [Anderson 1972], s’il est possible de se protéger contre des attaques externes (provenant de réseaux informatiques distants) en mettant en place des barrières de protection supplé-mentaires, il est par contre difficile de se prémunir contre les actions des utilisateurs malicieux. En particulier, les failles logicielles menant à l’obtention d’un accès de niveau administrateur fournissent à un pirate le moyen d’outrepasser complètement le DAC.
Pour intégrer un mécanisme de validation des accès entre sujets et objets, soit dans le système d’exploitation, soit directement dans les composants matériels, Anderson propose le modèle duMo-niteur de Référence(Reference Monitor). Celui-ci est configuré à partir d’une matrice d’accès fixe, définie par une entité tierce externe au système, et spécifiant exhaustivement quels accès sont autori-sés ou refusés entre les sujets et objets du système d’exploitation. Ainsi il devient possible de garantir que des droits d’accès considérés dangereux ne seront jamais donnés par erreur, puisque la matrice d’accès est fixe.
Le concept de Moniteur de Référence est au cœur de la définition du Contrôle d’accès obligatoire (Mandatory Access Control ou MAC). Ce terme, qui désignait initialement le modèle défini par Bell et LaPadula, a vu sa signification évoluer et représente aujourd’hui tout mécanisme qui place la gestion de l’attribution des permissions d’accès hors d’atteinte des utilisateurs concernés par ces permissions.
Les différents modèles présentés par la suite se positionnent à l’intérieur du Moniteur de Réfé-rence, comme mécanisme de validation. Ils ont tous pour objectif de spécifier une certaine politique de sécurité en matière de contrôle d’accès.
Modèle Bell-LaPadula
Le modèle Bell-LaPadula, établi par Bell[ et La Padula 1973], plus couramment appeléBLP, est issu des besoins en confidentialité des données du monde militaire. En plus des notions de sujet, d’objet et de matrice d’accès, le modèleBLP introduit la notion de label. Un label est associé à chaque sujet et objet du système, et contient un niveau de sécurité.Ceux-ci sont composés de deux types d’identifiants de sécurité :
1. un identifiant hiérarchique : le niveau de classification et le niveau d’habilitation pour les sujets, qui sont secret, top secret ; pour les objets, ou niveau de sensibilité, typiquement non classifié, confidentiel,
2. des identifiants de catégories : indépendamment de la hiérarchie de confidentialité, différentes catégories d’informations existent, et correspondent aux différentes organisations manipulant ces données.
Un niveau de sécurité s’écrit donc : (classification, ensemble de catégories). De plus, il existe une relation de dominance entre les niveaux de classification. Sur cette base, il est maintenant possible de définir de nouvelles règles qui s’appliqueront en plus de la matrice d’accès classique. Ces nouvelles lois sont :
ss-property Appeléesimple security property ou No Read Up, elle garantit que lorsqu’un sujet de-mande un accès en lecture sur un objet, son niveau est supérieur ou égal à celui de l’objet (cf. flèche de gauche sur la figure 2.3).
*-property Appeléestar-property ou No Write Down, cette loi garantit que lorsqu’un sujet demande un accès en écriture sur un objet, son niveau est inférieur ou égal à celui de l’objet (cf. flèche de droite sur la figure 2.3).
Le système est donc modélisé de la façon suivante : un ensemble de sujetsS, un ensemble d’objets O , une matrice d’accès M et une fonction donnant le niveau f. On dispose également d’un ensemble de permissions d’accès A = {e, r, a, w}. Elles sont classées suivant leur capacité d’observation (lec-ture) et d’altération (écriture) de l’information : e Ni observation ni altération (execute) ;
r Observation sans altération (read) ;
a Altération sans observation (append) ;
w Observation et altération (write).
Les deux lois sur les niveaux, illustrées par la figure 2.3, s’écrivent ainsi :
r ∈ M[s, o] ⇒ f(s) ≥ f(o)
a ∈ M[s, o] ⇒ f(s) ≤ f(o)
w ∈ M[s, o] ⇒ f(s) = f(o)
Ces lois signifient que 1) pour qu’un sujet s ait accès en lecture à un objet o, son niveau d’habili-tation f(s) doit être supérieur ou égal au niveau de classificationf(o) de l’objet, 2) pour qu’un sujet s ait accès en écriture à un objeto, son niveau d’habilitation doit être inférieur ou égal au niveau de classification de l’objet, et 3) pour qu’un sujet ait accès en lecture / écriture à un objet o, son niveau d’habilitation doit être égal au niveau de classification de l’objet.
Ce modèle a historiquement été implanté dans de nombreux systèmes d’exploitation. L’article de Bell et LaPadula décrit son intégration dans MULTICS, on le trouve également dans certaines versions de Solaris, HPUX ou autres systèmes UNIX. Il n’est pas désigné sous le nomBLP, mais plutôt MLS (Multi-Level Security) ou modèle de sécurité multi-niveaux. Par exemple, le système d’exploitation Unix System V/MLS intègre la gestion des niveaux de sécurité décrits dans le modèleBLP.
Toutefois ce modèle est difficile à appliquer tel quel à l’ensemble d’un système d’exploitation. Il est difficile d’attribuer des labels à certains sujets ou objets, par exemple le cas du dossier /tmp où tous les processus doivent pouvoir créer des fichiers. Des aménagements ont été prévus, le fait de migrer un objet d’un niveau de classification à un niveau supérieur lorsqu’il est accédé en écriture par un sujet de niveau supérieur (car normalement il est interdit de modifier un fichier de niveau inférieur). L’objet se trouve après l’accès au même niveau que le sujet. Mais l’effet néfaste lié à cet aménagement est que les objets ont tendance à être “tirés vers le haut”, et donc à tous se trouver sur le niveau le plus haut après un certain temps.
Par exemple, dans l’implantation MLS pour FreeBSD, on trouve des niveaux de sécurité spéciaux, low, equal et high, qui respectivement signifient un niveau toujours inférieur, toujours égal ou toujours supérieur lorsqu’ils sont appliqués. Par exemple, on peut affecter le niveauequal à un objet auquel on ne souhaite pas appliquer de politique particulière, low à un objet pour lequel on veut interdire l’écriture.
Un article ultérieur de [McLean 1987] restitue le modèleBLP de façon plus claire, et accompagnée de critiques concernant des failles apparaissant dans le modèleBLP lorsqu’il est appliqué à un système réel. Bell y a répondu par un autre article Bell[ 1988], dans lequel il précise que son étude concernait un modèle abstrait de système d’exploitation, et que les critiques de McLean sont infondées dans cette optique.
Modèle Biba
Le modèle BLP vu précédemment ne répond qu’à des besoins de confidentialité. C’est pour cette raison qu’un modèle complémentaire a été établi, qu’on peut qualifier de modèledual à BLP. Il s’agit du modèle Biba, d’après le nom de son auteur Biba[ 1975]. Il a pour objectif, de façon similaire à BLP, de traiter les problèmes de maintien de l’intégrité de l’information au sein du système d’exploitation.
A partir d’un modèle de protection similaire à celui vu pour BLP, il introduit une nouvelle fonction qui définit le niveau d’intégrité d’un sujet ou d’un objet. Deux lois permettent d’assurer l’intégrité :
No Read Down Un sujet n’est pas autorisé à accéder en lecture à un objet d’intégrité strictement inférieure, car cela pourrait corrompre sa propre intégrité (cf. flèche de gauche sur la figure2.4) ;
No Write Up Un sujet n’est pas autorisé à altérer le contenu d’un objet d’intégrité strictement supé-rieure (cf. flèche de gauche sur la figure 2.4).
Les deux lois s’écrivent (cf. figure 2.4) :
r ∈ M[s, o] ⇒ f(s) ≤ f(o)
a ∈ M[s, o] ⇒ f(s) ≥ f(o)
w ∈ M[s, o] ⇒ f(s) = f(o)
Ces lois signifient que 1) pour qu’un sujet s ait accès en lecture à un objet o, son niveau d’intégrité f(s) doit être inférieur ou égal au niveau d’intégritéf(o) de l’objet, 2) pour qu’un sujet s ait accès en écriture à un objet o, son niveau d’intégrité doit être supérieur ou égal au niveau d’intégrité de l’objet, et 3) pour qu’un sujet ait accès en lecture / écriture à un objeto, son niveau d’intégrité doit être égal au niveau d’intégrité de l’objet. Ces règles évitent à tout moment que se produise un transfert d’informa-tion d’un niveau d’intégrité bas vers un niveau d’intégrité haut, ce qui signifierait une compromission de l’intégrité du niveau haut.
A l’instar du modèle BLP, le modèle Biba est difficile à utiliser tel quel dans un système d’ex- ploitation. Ici l’idée est de migrer un sujet vers un niveau d’intégrité inférieur lorsqu’il accède à un objet de niveau inférieur. L’effet néfaste est que l’ensemble des sujets va rapidement se trouver en bas de l’échelle des niveaux d’intégrité. Dés lors, l’intérêt du modèle Biba est fortement remis en cause, puisqu’il n’y a plus de différence entre les sujets.
Modèle Clark-Wilson
Le travail de [Clark et Wilson 1987] est fondé sur la constatation de la différence entre les be-soins en sécurité du monde militaire et ceux du milieu commercial. En particulier, dans le monde du commerce, si la confidentialité des données est un point important, l’intégrité l’est encore davantage.
Dans ce modèle, on considère l’espace des donnéesD, composé de deux parties disjointes : les données intègres Constrained( Data Items ou CDI) et les données non intègres Unconstrained( Data Items ou UDI). On a : D = CDI ∪ UDI CDI∩UDI =∅
Deux classes de procédures sont définies : les IVP (Integrity Validation Procedure ou procédures de validations d’intégrité) et les TP (Transformation Procedure ou procédures de transformation). Les IVP sont utilisées pour trier les éléments deD, qui sont placés dansCDI si leur intégrité est validée, et dans U DI dans le cas contraire. Les TP sont les transactions valides du système, c’est-à-dire qu’elles ne perturbent pas l’intégrité des données auxquelles elles sont appliquées. L’intégrité des données est ensuite assurée par un ensemble de règles parmi lesquelles :
– Lorsqu’une TP est appliquée à un élément de CDI, le résultat reste dans CDI ;
– Certaines TP spécifiques peuvent prendre un élément de UDI en entrée, et produire un élément dans CDI.
Ce modèle repose sur des pratiques courantes concernant les données non informatisées du monde du commerce. Cependant, il est assez complexe à mettre en œuvre dans un système d’exploitation. En effet, il faudrait créer des IVP et des TP pour l’ensemble des programmes que l’on y trouve, ce qui s’avèrerait complexe, en particulier en ce qui concerne la vérification du bon fonctionnement d’un programme.
Modèle de la Muraille de Chine
Le modèle de politique de sécurité de la Muraille de ChineBrewer[ et Nash 1989] est issu, comme le modèle Clark-Wilson, des besoins du monde commercial. Son objectif est d’empêcher que des sujets aient accès simultanément à des données issues d’entreprise en concurrence. Les objets sont regroupés en“classes de conflit d’intérêt”, et la règle est qu’un sujet peut accéder au maximum à un seul objet de chacune de ces classes.
Le modèle reprend les concepts de sujets, objets et labels de sécurité introduits parBLP. Concer-nant les objets, ils sont classés suivant trois niveaux hiérarchiques :
1. Au niveau le plus bas, on trouve les données simples, typiquement les fichiers, qui sont les objets du système ;
2. Au niveau intermédiaire, les objets sont groupés suivant la compagnie à laquelle ils appar-tiennent, formant des ensembles de données ;
3. Au niveau le plus haut, les compagnies sont groupées suivant le fait qu’elles soient en concur-rence ou non. Ceci forme les classes de conflit d’intérêt mentionnées précédemment.
Dans le but de définir des lois d’accès similaires à BLP, les auteurs introduisent une matrice N qui contient l’historique des accès précédemment effectués. Il s’agit en fait de placer les sujets en ligne, et les objets en colonne, et dans chaque case un booléen indique si un accès a déjà eu lieu pour le couple (sujet, objet) correspondant. Ainsi deux règles régissent les accès entre sujets et objets :
– Simple security : l’accès en lecture à un objet est permis :
– s’il appartient à la même compagnie qu’un objet déjà accédé ;
– ou s’il appartient à une autre classe de conflit d’intérêt que les objets déjà en accès.
– *-property : l’accès en écriture à un objet est permis :
– si l’accès est autorisé par la règle de sécurité simple ;
– et si le sujet ne peut lire aucun objet d’une autre compagnie qui contiendrait de l’information non assainie.
Le terme “information assainie” désigne une information déguisée de manière à ce qu’il soit impossible de découvrir l’identité de la compagnie à laquelle cette information appartient. La règle *-property évite principalement qu’un utilisateur lise des données d’une compagnie et les écrive dans un fichier d’une autre compagnie, ce qui occasionnerait une fuite d’information.
Modèle DTE
Le modèle “Domain and Type Enforcement” ( DTE) [Boebert et Kain 1985] est assez différent des précédents dans le sens où il ne cherche pas à garantir la sûreté de la protection qu’il fournit. Il s’agit plutôt d’un mécanisme générique à partir duquel on peut implanter diverses politiques de sécurité dans un système d’exploitation. A partir d’implémentations disponibles pour les systèmes d’exploi-tation commerciaux [Badger et al. 1995], il est particulièrement efficace pour les problématiques de confinement de processus, comme illustré par [Walker et al. 1996]. Le confinement diffère des pro-priétés de confidentialité ou d’intégrité, en effet, son objectif est de spécifier, pour chaque sujet du système, un ensemble d’actions autorisées. Il se rapproche du modèle TAM sur l’utilisation du typage fort.
Concrètement, dans un système d’exploitation, les politiques de sécurité définies via le modèle DTE visent à :
– Restreindre les ressources accessibles par un programme, notamment les programmes privilé-giés (s’exécutant sous le compteroot), suivant le principe de “moindre privilège” décrit dans [Department of Defense 1991] ;
– Contrôler quels programmes ont accès aux ressources “sensibles”, et empècher l’accès par tout autre programme.
Par exemple, DTE peut être utilisé pour contrôler un programme tel que le serveur Webapache, afin de garantir par exemple que même s’il s’exécute sous le compteroot, il n’a accès qu’à ses fichiers de configuration, ses librairies et aux pages web. Il pourra également garantir que seul apache a accès à son fichier de configuration.
Le modèle reprend les principes de sujet, d’objet et de matrice d’accès. Toutefois, les lois d’accès n’opèrent pas sur les sujets, mais les domaines, et de même les objets sont englobés dans destypes. Ainsi chaque objet du système possède un type, et chaque processus s’exécute dans un domaine précis, dont découlent des droits d’accès.
DTE définit trois tables :
1. La table de typage, qui assigne les types aux objets du système ;
2. La table de définition des domaines (DDT) qui spécifie les droits d’accès (lecture, écriture, exécution, ajout, suppression) de chaque domaine sur les différents types ;
3. La table d’interaction des domaines (DIT) qui définit les droits d’accès entre domaines (créa-tion, destruction, envoi de signal).
La DDT définit également les “points d’entrée” des domaines, c’est à dire quels sont les fichiers binaires qui, une fois exécutés, vont créer un processus dans tel ou tel domaine. La définition des trois tables est effectué par un administrateur, et les utilisateurs ne peuvent pas les modifier. C’est pourquoi DTE rentre dans la catégorieMAC.
RBAC
Étant donné, d’une part, la difficulté d’application des modèles MAC dans les systèmes d’exploi-tation non-militaires, et d’autre part la faiblesse des modèles DAC, les études sur le contrôle d’accès se portèrent vers une nouvelle famille de modèle. Un premier article par Ferraiolo[ et Kuhn 1992] a mis en évidence le fait que, la plupart du temps, les permissions d’accès ne sont pas attribuées en fonc-tion de l’identité des utilisateurs. C’est plutôt le type d’activité qui les détermine, c’est-à-dire lerôle qu’occupe un utilisateur dans une entreprise ou une organisation. C’est ainsi qu’est conçu le modèle RBAC (Role-Based Access Control) ou contrôle d’accès déterminé par le rôle.
Par la suite, un article plus complet de [Sandhu et al. 1996] a posé de façon formelle les différents modèles qui forment le cœur de la famille RBAC. Les utilisateurs ont un certain rôle , qui caractérise leur activité. Chaque rôle est associé à un ensemble de permissions, qui représentent des possibilités d’accès aux objets du système. Enfin, l’utilisateur exerce son activité dans le cadre desessions, durant lesquelles il peut activer un sous-ensemble des rôles auxquels il appartient. Ce modèle simple est appeléRBAC0 (cf. figure 2.5).
Dans un autre article, [Ferraiolo et al. 1995] fournissent davantage de détails sur la conception et l’implantation de RBAC. Ils raffinent la notion de permissions comme étant une liste d’opérationssur les objets du système.
Hiérarchies de rôles
En plus du modèle simple RBAC0, [Sandhu et al. 1996] introduit la notions de hiéra rchiedans les rôles, dans le modèle RBAC1. L’objectif de la hiérarchie des rôles est l’introduction de la notion d’héritage des permissions entre les rôles, de façon analogue à l’organisation des métiers en entreprise,
où l’on trouve une hiérarchie organisée suivant le degré d’autorité et de responsabilité. Le modèle
RBAC1 apporte les définitions de rôles junior, avec des degrés de privilèges inférieurs, et des rôles
senior possédant des privilèges supérieurs. Dans les diagrammes de représentation des hiérarchies, ces derniers apparaissent typiquement vers le sommet, tandis que les rôles moins privilégiés sont placés plus bas.
Comme dans l’exemple de la figure 2.6, on peut envisager une hiérarchie appliquée au dévelop-pement de projets informatiques, où le rôle le plus bas est celui de “membre du projet”, et définit des permissions de base. Ensuite ce rôlé est hérité et raffiné par deux autres, “Développeur” et “Testeur”. Enfin le rôle de “chef de projet” hérite de toutes les permissions.
Contraintes
Le modèle RBAC2, proposé également par Sandhu[ et al. 1996], introduit le support des contraintes. Il ne s’agit toutefois pas d’un ajout au modèle RBAC1, car les hiérarchies de rôles ne sont pas supportées dans ce modèle. L’objectif des contraintes est de modéliser le fait que des rôles puissent être totalement disjoints, comme par exemple, au sein d’une entreprise, le directeur des achats et le directeur financier. Un même utilisateur ne peut en aucun cas appartenir à ces deux rôles simul-tanément, car il pourrait alors commettre des fraudes.
Les types de contraintes supportés dans RBAC2 sont généralement des considérations simples, c’est-à-dire dont la vérification et l’application se fait directement. Elles sont appliquées soit au niveau de l’attribution des rôles aux utilisateurs, soit au niveau de l’attribution des permissions aux rôles. Les principaux types de contraintes sont les suivants :
– Rôles mutuellement exclusifs : un même utilisateur ne peut être assigné qu’à un seul rôle dans un ensemble de rôle mutuellement exclusifs. Cette contrainte assure le principe de séparation des privilèges décrit dans [Clark et Wilson 1987] ;
– Cardinalité: contraintes sur le nombre maximal d’utilisateur assignés à un certain rôle ;
– Rôles pré-requis : dans certains cas, il est intéressant d’imposer des pré-requis en matière d’assignation de rôle ou de permissions. Par exemple, un utilisateur ne peut être assigné au rôle A que s’il appartient déjà au rôle B, et très souvent A sera un rôle senior par rapport à B.
Il est important de noter que les contraintes, quelles qu’elles soient, ne sont valables que si un contrôle strict est appliqué en ce qui concerne l’assignation des comptes d’utilisateurs aux êtres hu-mains. Si un employé possède deux comptes, eux-mêmes appartenant à deux rôles sensés être mu-tuellement exclusifs, les contraintes n’ont plus aucune efficacité.
Enfin, les hiérarchies de rôles peuvent aussi être définies comme des contraintes, et alors RBAC1 apparait comme un sous-ensemble de RBAC2. Cependant, le support direct des hiérarchies dans les implantations de RBAC reste préférable.
Modèle consolidé
Le dernier modèle présenté par Sandhu[ et al. 1996] est RBAC3, la combinaison de RBAC1 et RBAC2. Il supporte donc à la fois les hiérarchies de rôles et les contraintes sur l’assignation des rôles et des permissions. L’objectif de RBAC3 est essentiellement de résoudre les problèmes soulevés par la cohabitation de ces deux concepts : support des contraintes sur la hiérarchie de rôles, résolution de conflits entre l’héritage et les contraintes (par exemple quand un rôle hérite de deux rôles mutuelle- ment exclusifs).
Implantations système du contrôle d’accès
Dans la partie précédente nous avons abordé les modèles théoriques de contrôle d’accès. Au-delà de la définition de ces modèles, il est essentiel de disposer d’implantations fiables de ceux-ci sur les systèmes d’exploitation courants pour pouvoir réaliser pleinement leurs objectifs.
Nous nous intéresserons ici spécialement aux implantations disponibles pour le système Linux. Pour commencer, nous établirons une liste des implantations relevant des modèles théoriques présen-tés précédemment. Ensuite, nous étudierons plus spécifiquement deux implantations : SELINUX et grsecurity.
Les différentes implantations pour Linux
Le noyau Linux, au cœur des systèmes d’exploitations dits GNU/Linux, est relativement jeune comparé aux modèles théoriques que nous avons étudiés dans la section précédente. Toutefois, les implantations de modèles de contrôle d’accès type MAC et RBAC n’ont commencé que tard dans l’évolution de celui-ci. En effet, le développement de Linux a débuté en 1991, et les premières im-plantations de mécanismes avancés de contrôlé d’accès (c’est-à-dire autres que leDAC déjà intégré au noyau) ne sont apparues que vers 1997.
Les différentes implantations présentées par la suite sont :
– Medusa DS9 ;
– RSBAC ;
– LIDS ;
– SELINUX (présenté à part dans la partie2.2.2) ;
– grsecurity (présenté à part dans la partie2.2.3).
|
Table des matières
Introduction
1.1 Contexte de l’étude
1.2 Historique du contrôle d’accès
1.3 Objectifs de la thèse
1.4 Apports de la thèse
1.5 Plan du mémoire
2 Etat de l’art
2.1 Modèles théoriques de contrôle d’accès
2.1.1 DAC
2.1.2 MAC
2.1.3 RBAC
2.2 Implantations système du contrôle d’accès
2.2.1 Les différentes implantations pour Linux
2.2.2 SELinux
2.2.3 grsecurity
2.3 Langages d’expression de politiques de sécurité
2.3.1 Modèles multi-domaines
2.3.2 Modèles multi-politiques
2.3.3 Modèles méta-politiques
2.4 Conclusion
3 Discussion
3.1 Discussion des modèles de contrôle d’accès
3.1.1 DAC
3.1.2 MAC
3.1.3 RBAC
3.2 Implantations système
3.2.1 Medusa
3.2.2 LIDS
3.2.3 RSBAC
3.2.4 SELinux
3.2.5 grsecurity
3.3 Bilan sur le contrôle d’accès
3.4 Discussion des modèles d’expression de politiques
3.4.1 Modèles multi-domaines
3.4.2 Modèles multi-politiques
3.4.3 Modèles méta-politiques
3.4.4 Bilan sur les modèles d’expression de politique
3.5 Synthèse et orientations de notre architecture
3.6 Conclusion
4 Spécification
4.1 Principe de la Méta-Politique
4.1.1 Architecture distribuée
4.1.2 Deux niveaux de contrôle
4.1.3 Agent de mise à jour
4.1.4 Politique de protection
4.1.5 Politique de modification
4.1.6 Traducteur de politiques
4.2 Propriétés de l’architecture
4.2.1 Méta-politique
4.2.2 Evolution locale des politiques de sécurité
4.2.3 Intégration du MAC
4.2.4 Performance
4.3 Principe algorithmique de l’architecture Méta-Politique
4.3.1 Vue globale
4.3.2 Démarrage
4.3.3 Requête de mise à jour
4.4 Conclusion
5 Formalisation
5.1 Définition générale du modèle de Méta-Politique
5.1.1 Contextes de Sécurité
5.1.2 Vecteurs d’Interaction
5.1.3 Langage Neutre de Politique
5.1.4 Langage Neutre de Contraintes
5.1.5 Projection du langage neutre de politique
5.2 Définition de la Méta-Politique de contrôle d’accès
5.2.1 Modèle de contrôle d’accès
5.2.2 Langage neutre de contrôle d’accès
5.2.3 Projection du langage neutre de contrôle d’accès
5.2.4 Exemple d’application à l’administration du contrôle d’accès
5.3 Application de la Méta-Politique à la détection d’intrusion
5.3.1 Architecture multi-niveaux et multi-agents pour le contrôle d’accès et la détection d’intrusion
5.3.2 Méta-Politique de détection d’intrusion
5.3.3 Coopération du contrôle d’accès et de la détection d’intrusion
5.4 Conclusion
6 Vérification
6.1 Objectifs
6.2 Détection de flux d’information dans les politiques statiques
6.3 Influence de la Méta-Politique sur la vérification
6.3.1 Cas extrême 0
6.3.2 Cas extrême 1
6.3.3 Canevas générique
6.4 Méthode générale de vérification d’une Méta-Politique
6.4.1 Problème d’intersection des expressions régulières
6.4.2 Deuxième version de l’algorithme de contraction
6.5 Evaluation de la complexité de l’algorithme
6.6 Conclusion
7 Implantation
7.1 Implantation de l’agent de mise à jour
7.1.1 Chargement de la Méta-Politique
7.1.2 Réception des requêtes de mise à jour
7.1.3 Traitement des requêtes de mise à jour
7.1.4 Traduction vers le mécanisme de contrôle d’accès
7.2 Implantation des langages de politique
7.2.1 Format XML pour le langage neutre de politique
7.2.2 Format XML pour le fichier de Méta-Politique
7.2.3 Format XML pour les requêtes de mise à jour
7.3 Implantation des modules de traduction
7.3.1 Traduction de la politique neutre pour SELinux
7.3.2 Traduction de la politique neutre pour grsecurity
7.4 Conclusion
8 Conclusion
9 Bibliographie
Télécharger le rapport complet
