Windows

1 define confidentiality( $sc1 IN SCS, $sc2 IN SCO ) [ 2 SA { $sc2 >> $sc1 },

3 { not(exist()) };

4 ];

Listing 2.10 – Propriété de confidentialité exprimée enSPL

Les résultats fournis par PIGA sont dans ce cas des activités autorisées par la politique de contrôle d’accès directe qui conduisent à un flux indirect (en effet, dans la pratique, les flux directs sont déjà traités par leMAC, comme SELinux). On voit que PIGA améliore la sécurité par rapport à SELinux et permet de formaliser des propriétés de sécurité, ce que ne permet pas SELinux qui est de plus bas niveau.

2.3.2 Windows

Dans cette section, nous allons maintenant détailler des implantations de mécanismes de contrôle d’accès obligatoire pour les systèmes d’exploitation Windows.

2.3.2.1 Mandatory Integrity Control

MIC (Mandatory Integrity Control) est un mécanisme de contrôle d’accès obligatoire breveté par Microsoft [Richard Ward, 2006]. Ce modèle, plus récent que les implantations de SELinux et de grsecurity, a été mis en place à partir des systèmes d’exploitation Windows Vista.

À la différence des implantations présentes sous Linux, qui doivent être activées pour SE-Linux, et où il est nécessaire de modifier le noyau pour grsecurity, l’implantation de Microsoft est imposée. Son principal objectif est de protéger le système des attaques, qu’elles viennent de l’extérieur ou de l’intérieur.

Modèle général

Le modèle de protection s’inspire des modèles de Biba et deBLPque nous avons détaillé dans la section 2.2.2.2. Chaque entité du système, que ce soit les sujets ou les objets, possède un niveau d’intégrité [Microsoft, 2013]. Pour qu’un sujet puisse modifier un objet, il doit nécessairement posséder un niveau d’intégrité supérieur ou égal à celui de l’objet.

Cependant, nous avons vu que le modèle de protection défini par Biba était difficilement appli-cable à un système d’exploitation. Pour résoudre ce problème, Microsoft n’offre que la propriété denon modification des objetsayant une intégrité supérieure (No Write Up).

Politique et règle de contrôle d’accès

Par défaut, il existe cinq niveaux d’intégrité.

— le niveau de non confiance (Untrusted) qui concerne les processus appartenant aux sessions invitées et qui ne peuvent faire aucune interaction privilégiée sur le système ;

— le niveau d’intégrité bas est utilisé pour les processus ayant une forte exposition aux at-taques et qui possèdent souvent des failles de sécurité permettant d’entrer sur le système ;

— le niveau d’intégrité moyen qui est le niveau d’intégrité par défaut de l’utilisateur qui s’est connecté. C’est aussi le niveau d’intégrité sous lequel tourne la majorité des programmes lancés par l’utilisateur ;

— le niveau d’intégrité haut, qui est réservé à l’administrateur du système ;

— enfin, le niveau d’intégrité système réservé au système.

Tout comme le définit le modèle basé sur les niveaux d’intégrité de Biba 2.2.2.2, les sujets ayant une intégrité inférieure à celle de l’objet ne peuvent pas le modifier (No Write Upqui s’ap-plique spécifiquement aux objets du système). Mais à la différence du modèle théorique, la poli-tique de contrôle d’accès sous Windows n’empêche pas un sujet ayant une intégrité plus élevée que l’objet de le lire (principe duNo Read Down).

Les lois s’écrivent de la façon suivante :

a∈M[s, o]→f(s)≥f(o) w∈M[s, o]→f(s) =f(o)

FIGURE2.12 – Lois d’application des propriétés duMIC

Pour renforcer son implantation, Microsoft a mis en place, en plus des niveaux d’intégrité, des labels s’appliquant sur les sujets du système. Ces labels agissent en complément des niveaux d’intégrité. Ils permettent de renforcer le contrôle d’accès présent sur les systèmes Windows.

Par défaut, trois labels de sécurité sont définis :

— No Read Up: les sujets ayant une intégrité strictement inférieure à celle du sujet cible ne peuvent pas lire le contenu du sujet. Ce label empêche les processus d’intégrité basse

d’ob-server les processus ayant une intégrité plus haute. Ce label de sécurité est une application restreinte du modèle deBLP;

— No Write Up, s’applique ici sur les sujets du système : les sujets ayant une intégrité stricte-ment inférieure à celle des sujets ne peuvent pas les modifier, c’est l’application d’une des deux propriétés énoncées par Biba ;

— No Execute Up: restreint la permission d’exécution sur les objets par les sujets ayant un niveau d’intégrité bas.

La figure 2.13 illustre l’application du modèle de protectionMIC.

Niveau d’intégrité haut

Niveau d’intégrité moyen

Niveau d’intégrité bas No Write Up

No Read Up

No Execute Up

FIGURE2.13 – Modèle de protection des données :MIC

Cependant, dans le but d’assurer le fonctionnement du système, il existe des exceptions pos-sibles. Les utilisateurs autorisés à effectuer des tâches d’administration ont la possibilité de mo-difier leur niveau d’intégrité. L’objectif étant d’augmenter le niveau d’intégrité d’un processus pour qu’ils puissent réaliser les tâches privilégiées. Cette augmentation de privilège s’opère, par exemple, lorsqu’un utilisateur veut installer un nouveau logiciel ou réaliser une mise à jour.

Cette autorisation d’augmentation du niveau d’intégrité est représentée par le jeton d’accès Administrateur. Il autorise ainsi les processus à écrire dans les répertoires modifiables unique-ment par l’administrateur. Depuis Windows Vista, il n’existe plus de compteAdministrateursous Windows. On peut rapprocher la possibilité d’augmentation du niveau d’intégrité pour un utilisa-teur de la commandesudosous Linux, qui permet de changer l’environnement de l’utilisateur, généralement dans le but d’effectuer des tâches d’administration.

Ce modèle de contrôle d’accès est mis en place pour protéger le système et les fichiers systèmes des attaques qui pourraient modifier leur intégrité. À la différence des implantations de mécanisme de contrôle d’accès sous Linux utilisant les LSM, le contrôle du MIC est fait avant le contrôle des droits d’accès discrétionnaire. Cela entraîne la possibilité pour l’utilisateur élevant son niveau d’intégrité par le jeton d’accès Administrateur de contourner les droits d’accès classiques. En effet, une fois son intégrité modifiée, il se retrouve avec des privilèges administrateur ce qui lui permet de contourner les droits d’accès discrétionnaire et lui offre presque tous les droits.

Cette implantation d’un mécanisme de contrôle d’accès obligatoire est la première réalisée par Microsoft. Elle a l’avantage de proposer une approche plus simple que SELinux ou grsecurity puisqu’il n’est pas nécessaire d’écrire une politique énumérant tous les privilèges. En pratique, il

ne protège pas les données des utilisateurs accessibles via le jeton d’accès Administrateur. Ainsi,

MICne permet pas de minimiser les privilèges, ce qui autorise de nombreuses violations de confi-dentialité et d’intégrité car il n’implante qu’une partie du modèle de protection de Biba.

2.3.2.2 PRECIP

PRECIP (Practical and Retrofittable Confidential Information Protection) [Wanget al., 2008]

est un mécanisme de gestion des flux d’information directs développé pour Windows XP. Il im-plante une simplification du modèle deBLP. En plus d’un mécanisme de contrôle, il est fourni avec une suite d’outils aidant à son administration.

Modèle général

PRECIP associe deux niveaux de sécurité aux objets du système. Ces niveaux sont "haut" et

"bas". Les sujets possèdent aussi deux niveaux de sécurité trust et untrusted. Pour qu’un sujet puisse accéder à un objet ayant un niveau haut, il doit être considéré comme "de confiance".

Cette modélisation est une implantation sur un système réel, ici testée sur Windows XP, du modèle de BLP. L’objectif de cette implantation est de respectée la confidentialité du système, même en cas d’attaque.

Cette implantation d’un mécanisme de contrôle d’accès obligatoire est l’une des premières présente sur les systèmes d’exploitation Windows. Elle implante une simplification de modèle de confidentialité définie par BLP. Cette implantation se base sur le suivi des flux implicites et ex-plicites et sur l’utilisation de l’étiquette dynamique des données. Cependant, le modèle est limité à seulement deux niveaux de confidentialité. De plus, les règles sont limitées et ne protègent pas le système complet, juste les fichiers considérés comme sensibles. Les règles ne sont pas appli-cables à tout le système et elle ne sont pas extensibles. Enfin, les résultats montrent un impact non négligeable sur les performances du système d’exploitation ainsi que sur le fonctionnement des applications [Wanget al., 2008].

Politique et règle de contrôle d’accès

PRECIP définit deux niveaux de confidentialité pour les objets du système :highetlow. Ces informations sont stockées dans les flux NTFS des objets. Les sujets peuvent avoir deux niveaux de sécurité :trustetuntrusted. Ces niveaux sont stockés dans une structure du noyau. La détermi-nation de ces niveaux est faite sur l’établissement d’une base de données fournie par l’outil.

Un sujet est considéré commede confiance si l’outil a pleinement conscience de toutes les entrées et toutes les sorties possibles de l’exécutable. Si ce n’est pas le cas, il sera alors marqué comme de non confiance. Les niveaux de confidentialité des objets du système sont dérivés des droits d’accès discrétionnaire. Par exemple, un fichier dont le propriétaire est l’administrateur est considéré comme sensible.

La définition des niveaux de confidentialité peut aussi être faite par le propriétaire des fichiers grâce aux outils fournis par PRECIP. Des outils spécifiques, permettant de faire transiter des pro-cessus en mode sensible comme les navigateurs Internet qui vont sur les sites sensibles, ont aussi été mis en place.

2.3.2.3 Core Force

Core Force [Labs, 2005] est une suite d’outils divisée en deux parties : un pare-feu et un mécanisme de contrôle d’accès. Core Force permet de confiner les processus et contrôler leurs privilèges.

1 <Programs>

2 <Program Name="Mozilla Firefox 1.0" SecurityLevel="MediumLow" Status="

Enabled">

Listing 2.11 – Extrait d’un fichier de configuration de Core Force pour un programme

1 <Policies>

2 <Policy Name="General. Environment for Mozilla Firefox">

3 <Documentation>A Policy includes previously defined configuration parameters.</Documentation>

Listing 2.12 – Extrait d’un fichier de configuration de Core Force pour un programme spécifiant les permissions

Modèle général

Core Force se base sur le modèle de grsecurity pour faire du contrôle d’accès, c’est-à-dire qu’il va appliquer le triplet (r,w,x) pour chaque objet du système. Comme grsecurity ou SELinux, il est nécessaire de définir explicitement les interactions autorisées pour chaque application du système.

Core Force est fourni sous la forme d’un logiciel, installable uniquement Windows 2000 et sur Windows XP. Il est composé de deuxdrivernoyau, un qui contrôle des interactions sur le système de fichiers et sur le registre, et le second pour contrôler les interactions du réseau.

La configuration par défaut définie des profils de sécurité pour les applications. Ces profils sont des templates de sécurité, qui proposent des politiques de sécurité par défaut vis-à-vis du profil sélectionné. Il est cependant possible de créer des profils spécifiques pour les applications.

Politique et règle d’accès

La politique de contrôle d’accès s’appuie sur le chemin complet des sujets et des objets. Tout comme grsecurity, une règle de contrôle d’accès associe un sujet à un objet avec un ensemble de permission qui se définissent grâce auxACL.

Pour configurer les permissions pour les applications, Core Force propose une interface gra-phique facilitant la configuration du contrôle d’accès. Les permissions sont ensuite stockées dans des fichiers au format XML.

Nous allons détailler un exemple de politique. Tout d’abord, le fichier XML spécifie pour quel programme s’applique cette politique 2.11.

Ensuite, le fichier de configuration spécifie les interactions autorisées par le programme 2.12.

Nous pouvons noter ici que le programmeFirefoxa le droit de lecture et d’écriture sur le fichier pluginreg.datdans le dossierMozilla.

L’approche Core Force a été abandonnée depuis l’arrivée de Windows Vista, 7 et 8.