Soutenance mémoire
Depuis quelques années, les systèmes embarqués sont en plein essor, notamment avec l’arrivée des objets connectés dans les foyers. À l’inverse des ordinateurs classiques (serveur, portable ou station de travail), ces systèmes informatiques sont intégrés dans des objets dont la fonction principale ne se résume pas à celle d’un ordinateur, comme un four à micro-ondes, un téléphone ou un système de contrôle industriel. Ces systèmes embarqués ont souvent la contrainte principale de posséder des ressources limitées. Toutefois, cette définition est très générique et la frontière avec l’informatique classique est assez floue. Le monde des systèmes embarqués est vaste et comprend des systèmes de nature et de capacité très diverses. Nous pouvons typiquement distinguer deux catégories de systèmes embarqués :
— les systèmes qui n’utilisent pas de système d’exploitation (Operating System (OS)), ou un système d’exploitation temps-réel, et qui ont recours à un microprocesseur aux ressources limitées, souvent un microcontrôleur, par exemple un processeur de la famille ARM Cortex-M) ;
— les systèmes qui utilisent un OS complexe (rich OS) et un microprocesseur plus puissant (application processor ), par exemple un processeur de la famille ARM Cortex-A.
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 6 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. 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.
|
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
