SELinux

SELinux(Security-Enhanced Linux) est un mécanisme de contrôle d’accès obligatoire créé par laNSAet intégré nativement dans les noyaux Linux. Il est proposé sous la forme de module

de sécurité s’interfaçant avec les crochets de sécurité (Security Hooks) du noyau (Linux Security Module(LSM) [Wrightet al., 2002]).

Basé sur le modèle deDTE, SELinux implante les propriétés de moindre privilège et de confi-nement des processus pour garantir la confidentialité et l’intégrité. Son architecture est basée sur FLASK[Spenceret al., 1998], une architecture spécifiquement créée pour SELinux, qui offre une couche d’abstraction entre le système et le mécanisme de contrôle d’accès sous-jacent, transfor-mant les ressources du système en contexte de sécurité. Ainsi les ressources du système ne sont pas identifiées par leur nom ou par leur chemin, mais par des contextes de sécurité.

L’écriture d’une politique SELinux étant complexe, SELinux utilise également le modèle

RBAC pour réduire la taille de la politique. Ainsi, les utilisateurs sont associés à des rôles qui peuvent ensuite accéder à des domaines, et ce sont les domaines qui agissent sur les types.

Modèle général

Chaque utilisateur du système (utilisateur standard, mais aussi administrateur) est associé à une identité SELinux unique. Cette identité SELinux peut être partagée par plusieurs utilisateurs.

L’identité SELinux est associée à un rôle par défaut, mais elle peut aussi accéder à un ensemble de rôles. Les utilisateurs ont la possibilité de changer de rôle sans changer de session ou de compte utilisateur. Les rôles accèdent ensuite aux domaines.

Chaque ressource du système possède un contexte de sécurité qui la caractérise. Le contexte de sécurité est considéré comme une couche d’abstraction entre les ressources et le mécanisme de contrôle d’accès. Il contient les informations nécessaires au modèleDTE(domaines ou types).

Contextes de sécurité

L’architecture FLASKcrée une couche d’abstraction pour la représentation du système qui lui permet de n’être qu’une interface entre le système d’exploitation et le mécanisme de contrôle d’ac-cès sous-jacent. Cette abstraction permet l’association de contextes de sécurité avec les ressources du système.

Les contextes de sécurité sont définis par leserveur de sécuritéqui constitue un moniteur de référence au sens d’Anderson. Pour SELinux, un contexte de sécurité est constitué de plusieurs attributs :

— une identité qui est liée aux identités des utilisateurs Linux présents sur le système. Ainsi, plusieurs utilisateurs standards peuvent avoir la même identité SELinux. Cette identité SE-Linux a la particularité de ne pas pouvoir être modifiée aux cours des interactions réalisées.

Seuls certains programmes d’authentification ont la capacité de pouvoir changer les iden-tités SELinux ;

— un rôle : un utilisateur SELinux a accès à un ensemble de rôles. Ce sont ces rôles qui déterminent les interactions autorisées pour l’utilisateur ;

— un domaine, qui est le domaine d’exécution du processus ;

— un type, qui est le type d’un objet du système autre qu’un processus ;

— une catégorie : cet attribut est la représentation de l’implantation du modèle Multi-Categorie Securityde SELinux. Il permet de définir des conteneurs pour les utilisateurs dans le but de les isoler les uns des autres. Les catégories permettent d’isoler des popula-tions ayant la même identité SELinux. Il est possible d’avoir plusieurs catégories pour un même contexte de sécurité.

— un niveau d’habilitation : cet attribut est l’application du modèle de BLP. Les niveaux d’habilitation peuvent être une valeur unique ou une plage de niveaux. C’est l’implantation du modèleMulti-Level Securityde SELinux.

Un contexte de sécurité est représenté au niveau du système de fichiers par une chaîne de caractères de la manière suivante :id:rôle:type:catégories:sensibilités.

Un utilisateur possède une identité SELinux de part son identité standard Linux. Cette identité SELinux lui permet d’accéder à certains nombres de rôles SELinux. Ces rôles peuvent accéder à des domaines. Les domaines peuvent à leur tour accéder à d’autres domaines ou à des types. Ce modèle est illustré par la figure 2.10.

Identité

FIGURE2.10 – Implantation des modèlesRBACetDTEpar SELinux

Pour les objets du système, les contextes de sécurité sont stockés dans le système de fichiers au niveau des attributs étendus.

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

Les domaines effectuent des interactions sur les objets du système qui possèdent tous un type.

Une interaction se caractérise par la règle suivanteD−(P)− > T, ouDest le domaine,P les permissions et T le type. Le cas spécifique d’une interaction entre deux domaines se traduit de manière similaireD1−(P)−> D2.

La politique de contrôle d’accès de SELinux se divise en deux. D’un côté, nous trouvons les règles faisant la correspondance entre les ressources du système et leur contexte de sécurité spécifique. De l’autre, nous trouvons les règles d’accès et de transition.

Les règles d’accès définissent de manière explicite les interactions autorisées par des domaines sur des types du système. Les règles de transition sont les règles qui autorisent la création de nouveau domaine à partir de type spécifique.

La définition d’une règle d’accès dans la politique SELinux se fait donc de la manière sui-vante 2.1.

1 allow linpack_t etc_t:file { read open getattr };

Listing 2.1 – Règle d’accès dans une politique SELinux

Cette règle autorise (allow) le domaine linpack_tà lire, ouvrir et récupérer les attributs des fichiers file { read open getattr } ayant pour type etc_t. Concrètement, cette règle autorise un processus ayant pour domaine linpack_tà aller lire des fichiers de configurations présents dans /etc.

Pour autoriser le rôlestaff_rà accéder au domainelinpack_t, il suffit d’ajouter la règle 2.2.

1 role staff_r types linpack_t;

Listing 2.2 – Règle d’autorisation pour un rôle pour accéder à un type dans une politique SELinux

Le dernier type de règle concerne les transitions. Ce sont des opérations spécifiques qui sur-viennent lors de la création d’un nouveau domaine. La définition d’une règle de transition se définit de la manière suivante 2.3 :

1 type_transition staff_t mozilla_exec_t:process mozilla_t;

Listing 2.3 – Règle de transition dans une politique SELinux

Cette règle autorise le domaine staff_t à faire transiter un type mozilla_exec_t vers le do-mainemozilla_t. Cette règle est par exemple, appliquée lorsqu’un utilisateur du staff exécute le programmeFirefox.