SELinux : DTE, RBAC, ...

Contrôles d'accès DAC, MAC et RBAC

Discretionary Acess Control - DAC

Le modèle DAC (Discretionary Access Control) est un modèle de contrôle d'accès défini comme un «moyen de restreindre l'accès aux objets en fonction du sujet (ou du groupe) auxquels ils appartiennent». L'aspect discrétionnaire est du au fait que c'est le sujet qui gère les contrôles de l'objet («à la discrétion du propriétaire»), en fonction des droits qu'il possède sur ledit élément.

Une des limitations du modèle DAC est la difficulté à administrer modèle, ou encore l'absence d'une granularité fine (plus la granularité augmente, plus l'administration devient complexe).

En guise d'exemple, le contrôle d'accès de base mis en place sur les systèmes d'exploitation UNIX/Linux respecte ce principe discrétionnaire.

Mandatory Acess Control - MAC

D'une manière un peu opposée, le modèle MAC (Mandatory Access Control) été défini par les Trusted Computer System Evaluation Criteria (ou TCSEC) comme un «moyen de restreindre les accès au objet en se basant sur leur sensitivité». Le modèle de Bell et Lapadula se base par exemple sur deux règles MAC, no read-up (interdiction de lire à des niveaux de sensibilité supérieur à celui de l'utilisateur) et no write-down (interdiction d'écrire à des niveaux de sensibilité inférieurs à celui de l'utilisateur). Ces règles permettent d'assurer la confidentialité des informations. D'une manière opposée, le modèle Biba assure l'intégrité par les règles no write up et no read down.

Un des aspects les plus importants du modèle MAC est la notion mandatoire. Ainsi, les utilisateurs n'ont pas un total contrôle de leurs objets car les politiques MAC définies par l'utilisateur sont celles qui déterminent les droits fournies à chaque utilisateur, contrairement au modèle DAC.

Role-Based Access Control - RBAC

Role-Based Access Control (RBAC), ou contrôle d'accès à base de rôles, est un modèle de contrôle d'accès dans lequel chaque décision d'accès se base sur le rôle auquel l'utilisateur est associé.

Le modèle RBAC peut être caractérisé par deux relations : Les utilisateurs du système se voient attribuer des rôles auxquels sont associées des permissions/autorisations. Une autorisation est donc accordée à un utilisateur si celle-ci est associé à l'un de ses rôles (sous certaines contraintes telles que l'impossiblité d'avoir d'exploiter deux rôles en même temps). Ainsi, il s'agit d'une nouvelle alternative aux modèles discrétionnaire et mandatoire présentés précédemment.

Différents niveaux du modèle RBAC (RBAC0, RBAC1, RBAC2, RBAC3) ont été définis, afin d'assurer un maximum de sécurité et de fournir une expressivité (notions de hiérarchisation des rôles, de sessions, ...) permettant de répondre aux besoins des entreprises. Le modèle de base peut être toutefois caractérisé par les entités suivantes :

• S = Subject
• R = Role
• P = Permissions

Les association entre les entités sont caractérisés par trois relations :

• SA = Subject Assignment, SA appartient à S * R
• PA = Permission Assignment, PA appartient à P * R
• RH = Role Hierarchy, RH appartient à R * R

(Domain) Type Enforcement - (D)TE

Le modèle Type Enforcement permet d'associer des labels aux différentes entités du système. Les principaux attributs sont le rôle et l'utilisateur. Les entités activés (également appelées sujets) ont également un attribut domaine tandis que les entités passives ont un attribut type. Le modèle Type Enforcement effectue alors un contrôle d'accès avec la table d'accès définis par les différentes règles de la politique de sécurité. Domain and Type Enforcement (DTE) est une version avancé du modèle Type Enforcement (TE).

Domaines, sujets, et objets

La politique DTE permet de définir des contrôles d'accès entre les sujets (processus, domaines) et les objets (fichiers, répertoires, sockets, ..). Quatre éléments qualifient ces autorisations :

• le type de la source type, le domaine
• le type de la cible
• la classe de l'objet
• les permissions accordées

La syntaxe d'une règle est donc regle source cible:objet permission. Il est à noter qu'a moins qu'une règle n'autorise un accès, SELinux l'interdit. Ce modèle fonctionne donc sur une politique fermée, ce qui le rend beaucoup plus sûr. Les éléments source, cible, objet et permission désignent des éléments SELinux. Toutefois, il est également possible d'utiliser les caractères de généricité (*), de soustraction (-), de complétude (~) ou d'ensemble ({}) afin d'obtenir des règles plus précises.

Comme indiqué précédemment, les objets sont labellisés par trois attributs, l'utilisateur, le rôle et le type, tandis que les sujet sont labellisés par l'utilisateur, le rôle et le domaine d'exécution. La syntaxe de ces labels est utilisateur:rôle:{type|domaine}. Par exemple, le label root:sysadm_r:sysadm_t est celui par défaut obtenu lors d'une connexion en tant que root sur la machine.

Règles

Le modèle TE est caractérisé par deux grandes catégories de règles. Les règles dites Access Vector (AV) définissent les contrôles d'accès tandis que les règles de types permettent de gérer les transitions de type ou leur poly-instanciation.

Cinq règles de type AV, allow, dontaudit, auditallow, auditdeny et neverallow, ont été définies.

• Allow définit les accès autorisés. La règle allow user_t self : process * permet par exemple d'autoriser l'exécution de processus de type user_t par les sujets de type user_t.
• La règle neverallow permet de définir des invariants. La politique SELinux étant fermée (tout ce qui n'est pas définis comme autorisé est interdit), neverallow permet donc de s'assurer que les règles existantes n'autorisent pas un accès non voulu (sinon, la police définie ne sera pas compilable et donc utilisable).
• Enfin, auditallow permet la génération de logs lors des accès à certaines ressources tandis que dontaudit permet d'éviter la génération de logs lors de certaines tentatives d'accès non autorisées.

Pour les transitions de types, trois règles sont définies : type_transition, type_change et type_member.

• Type_transition permet de définir le type des nouveaux objets ou lors de la transition des processus. Par exemple, type_transition src_type tgt_type : file-related default_type ; indique que les objets relatifs aux données (fichier, répertoire, ...) créés par un processus de type src_type dans un répertoire de type tgt_type auront le type default_type.
• Type_change et type_member sont des règles permettant de faire des contrôles avancés tels que la poly-instanciation ou les applications SELinux-aware.