Politiques de contrôle d’accès et politiques de contrôle de flux d’information

Politiques de contrôle d’accès et politiques de contrôle de flux d’information

Politiques de contrôle d’accès

Parmi les mécanismes de sécurité, le contrôle d’accès est l’une des solutions les plus répandues dans les systèmes d’exploitation avec une première apparition en 1965 dans le système d’exploitation Multics [10, 11], suivi quelques années plus tard par les systèmes d’exploitation Unix, Linux et Windows. Le contrôle d’accès permet de vérifier en amont de toute action sur un objet ou une ressource que l’utilisateur à l’origine de la requête d’accès est habilité à réaliser cette action. Un mécanisme de contrôle d’accès repose sur un moniteur de référence qui étudie la requête envoyée par le sujet et qui autorise ou refuse l’accès à cet objet. Ce moniteur de référence peut-être incorporé dans les différentes couches du système. En effet, le contrôle d’accès peut être implémenté dans une application, dans un intergiciel, dans un système d’exploitation, ou dans des composants matériels. L’expression d’une politique de contrôle d’accès s’appuie donc sur les entités suivantes :

Un objet ou une ressource qui permet de recevoir, d’envoyer, ou de stocker de l’information.
Un sujet qui est l’identité de l’utilisateur ou de l’application qui souhaite accomplir une action sur un objet ou une ressource.
Un ensemble de droits d’accès qui correspond aux actions que le sujet est autorisé à mener sur un objet ou une ressource. Par exemple : la lecture, l’écriture, la modification, la suppression, etc.

En 1974, Lampson propose de représenter une politique de contrôle d’accès grâce à une matrice A impliquant les trois entités précédemment citées [12]. Les lignes de la matrice désignent les sujets, les colonnes déterminent les objets ou les ressources. L’élément A[i, j] décrit les droits d’accès que le sujet i possède sur l’objet j. Ces droits d’accès représentent les types d’actions que l’utilisateur est autorisé à effectuer sur le fichier, par exemple : la lecture, l’écriture. Pour illustrer les limitations du contrôle d’accès, supposons un système contenant un fichier notes.txt qu’Alice peut lire et modifier, un fichier fuite.txt que Bob peut lire et modifier et un utilisateur Eve qui souhaite accéder aux informations contenues dans le fichier notes.txt de Alice.

La question de la définition (et de la modification) des droits d’accès pour un objet est donc un élément déterminant dans la sécurité des modèles de contrôle d’accès qui se divisent principalement en deux catégories distinctes : le contrôle d’accès discrétionnaire Discretionary access control (DAC) et le contrôle d’accès obligatoire Mandatory access control (MAC).

Le contrôle d’accès discrétionnaire (DAC) autorise la modification de la politique de contrôle d’accès d’un objet uniquement à son propriétaire. La notion de propriétaire est modélisée par un droit d’accès spécifique que possède un sujet sur un objet. Généralement, le propriétaire initial est le créateur de l’objet. Par exemple, le propriétaire du fichier notes.txt a le privilège de pouvoir modifier à sa guise les autorisations accordées aux autres utilisateurs. C’est donc un modèle décentralisé puisque chaque utilisateur a la capacité de modifier les permissions de ses propres fichiers. Il est alors difficile pour un administrateur d’avoir une vision globale de la sécurité du système.

Le contrôle d’accès obligatoire (MAC) ne donne pas de privilège au propriétaire d’un objet, seul l’administrateur du moniteur de référence a la capacité de modifier les permissions d’un objet. C’est donc un système centralisé dans lequel une autorité de confiance initie et modifie les permissions dans le système.

Les besoins du gouvernement des États-Unis d’Amérique en termes de confidentialité de l’information ont conduit le U.S. Department of Defense (DoD) à créer un modèle de politique de contrôle d’accès obligatoire multiniveau. Conçu par Bell et La Padula [13, 11], le modèle est basé sur une classification multiniveaux permettant le contrôle d’accès aux informations selon l’accréditation de l’utilisateur. Chaque utilisateur (ou sujet) possède un niveau d’habilitation et chaque objet est associé à un label de sécurité. Ces niveaux d’habilitation et labels de sécurité sont ordonnés. Par exemple, en France, les niveaux d’habilitation et de classification pour la protection du secret défense sont ordonnés de la manière suivante : « Très Secret Défense » > « Secret Défense » > « Confidentiel Défense ». Ce type de politique vise à s’assurer que les informations de niveau x puissent être lues uniquement par des utilisateurs accrédités à un niveau y, avec y > x. En pratique, pour implémenter ce type de politique au sein d’un ordinateur, il faut vérifier deux règles :

— Un sujet de niveau s peut lire les objets de niveau o si et seulement si s > o (read down ou Simple Security Property)
— Un sujet de niveau s peut modifier les objets de niveau o si et seulement si s < o (write up ou Start Security Property) .

La première règle paraît assez naturelle. La seconde, moins intuitive, permet de s’assurer qu’un sujet malveillant, ou compromis, ne pourra en aucune manière provoquer une fuite d’information vers un niveau inférieur. Ce type de modèle permet donc de se prémunir des attaques illustrées par la figure 1.2. Le modèle de Bell LaPadula garantit avant tout la confidentialité des informations. En effet, ce modèle autorise un utilisateur à lire uniquement les informations contenues dans les objets ou ressources ayant un niveau de sécurité inférieure ou égale à son niveau d’accréditation. L’intégrité des informations n’est malheureusement pas assurée, car ce même utilisateur peut écrire dans n’importe quel objet ayant une classe de sécurité supérieure ou égale à son accréditation. Le modèle dual proposé par Biba [14] permet d’assurer l’intégrité des données. Ces modèles de politique de contrôle d’accès multiniveaux permettent de prévenir toute fuite ou modification d’information par un sujet qui ne possède pas le niveau d’accréditation nécessaire pour lire ou modifier l’information en question. Cependant, ces modèles sont en pratique peu utilisés, car ils sont très restrictifs. Par exemple, dans le modèle de Bell-LaPadula, un sujet ne peut simultanément accéder en lecture à des objets de niveau n et en écriture à des objets de niveau m < n, même si son exécution ne provoque aucune fuite d’information du niveau n vers le niveau m. Cette restriction limite en pratique l’usage de ces modèles à des contextes très spécifiques, typiquement dans des usages militaires ou gouvernementaux. Toutefois, la plupart des usages s’accommodent mal de ces règles contraignantes. Ainsi, un utilisateur souhaite généralement exécuter simultanément (c’est-à-dire dans la même session) différentes applications (client SSH, navigateur Web, client de courriel, etc.) et que ces applications puissent lire et modifier leurs fichiers. Pour autant, on souhaite s’assurer qu’une application malveillante ou compromise ne pourra atteindre à la confidentialité ou l’intégrité des données d’une autre application.  Bien que très répandu, le contrôle d’accès permet de mener des vérifications uniquement avant l’accès à un objet. Une fois l’autorisation d’accéder à l’objet accordée, la propagation de ces données dans le système échappe totalement au contrôle d’accès. Cela peut conduire à des fuites d’information sans violation apparente de la politique de contrôle d’accès. Pour se prémunir contre de telles attaques, il est nécessaire de recourir à des modèles de contrôle d’accès obligatoire, qui sont en pratique trop restrictifs. Pour pouvoir régler le problème de fuite d’information et contrôler de manière précise la propagation des données après leur accès, il est donc essentiel de raisonner en termes de flux d’information et de vérifier que toute propagation d’une information respecte la politique de sécurité voulue. Ce mécanisme est connu sous le nom de « contrôle de flux d’information », Information Flow Control (IFC) en anglais.

Politiques de contrôle de flux d’information 

Dans les années 1970, plusieurs chercheurs ont commencé à se pencher sur les flux d’information. Fenton [15] s’est d’abord intéressé au développement d’un système permettant de se prémunir des fuites d’information grâce au marquage des données avec un niveau de sécurité. Pour les flux d’information, nous parlerons de conteneurs d’information pour décrire les objets abstraits qui permettent de stocker de l’information. Un flux d’information se produit donc lorsqu’une information est propagée entre un conteneur d’information source A et un conteneur de destination B. Afin de définir plus formellement cette notion de propagation de l’information, plusieurs propriétés ont été proposées dans la littérature. Goguen et Meseguer [16] ont énoncé proposé la propriété de non-interférence qui a largement été adoptée par la communauté. Cette propriété permet de s’assurer que plusieurs exécutions d’un programme dont seules les données sensibles ont été modifiées produisent les mêmes données publiques, visibles par un attaquant.

Table des matières

Introduction
1 État de l’art
1.1 Politiques de contrôle d’accès et politiques de contrôle de flux d’information
1.1.1 Politiques de contrôle d’accès
1.1.2 Politiques de contrôle de flux d’information
1.2 Mécanisme de contrôle de flux d’information vu comme une machine abstraite
1.3 Mécanismes de contrôle de flux d’information statique
1.3.1 Approche basée sur la sémantique du langage
1.3.2 Approche basée sur les systèmes de typage statique
1.4 Mécanismes de contrôle de flux d’information dynamique
1.4.1 Approche basée sur l’environnement d’exécution
1.4.2 Approche basée sur l’instrumentation de code binaire
1.4.3 Le contrôle de flux d’information dans les systèmes d’exploitation
1.4.4 Le contrôle de flux d’information réalisé matériellement
1.4.4.1 In-core
1.4.4.2 Off-loading
1.4.4.3 Off-core
1.5 Combinaison conjointe d’analyse statique et dynamique
1.6 Conclusion
2 Contrôle de flux d’information par utilisation conjointe d’analyse statique et dynamique
2.1 Hypothèses et architecture générale
2.1.1 Hypothèses et architecture matérielles
2.1.2 Hypothèses et architecture logicielles
2.2 Extraction passive de l’activité du processeur grâce aux composants de débogage et de traces du processeur
2.3 Organisation des annotations et transformation de l’application en vue de son harmonisation avec les traces générées
2.4 Flux d’information dans l’architecture matérielle du système
2.4.1 Représentation des étiquettes pour les différents conteneurs d’information inhérents à l’architecture matérielle.
2.4.2 Annotations pour les instructions générales
2.4.3 Annotations pour les instructions manipulant la mémoire
2.4.4 Gestion des flux implicites à l’aide de la pile d’étiquettes du registre PC
2.5 Extraction d’informations par instrumentation du programme utilisateur
2.6 Analyse dynamique lors de la communication avec le système d’exploitation
2.6.1 Étiquetage des fichiers
2.6.2 Suivi de flux d’information mettant en jeu des fichiers
2.7 Stockage des annotations
2.8 Moniteur de sécurité optimisé pour le suivi de flux d’information
2.9 Conclusion
3 Politiques de sécurité et résultats expérimentaux
3.1 Expression des politiques de sécurité
3.2 Protection des fichiers du système à l’aide d’une politique de sécurité
3.3 Protection de l’exécution de l’application
3.3.1 Politique de sécurité pour l’intégrité du flot de contrôle
3.3.2 Politique de sécurité pour les erreurs mémoires temporelles sur le tas
3.3.3 Politique de flux d’information pour les données provenant d’un canal de défiance
3.4 Impacts sur les performances
4 Conclusion

Télécharger le rapport complet