Contrôle d'accès à base de règles

Requêtes

Le contrôle d'accès de RSBAC est déclenché lors de l'exécution d'appels système, grâce à des hooks sur mesure. Pour appliquer son contrôle d'accès, RSBAC formalise ses requêtes en trois parties :

• le sujet, c'est-à-dire le processus qui fait la requête. Un processus agit pour le compte d'un utilisateur, ce qui donne des attributs supplémentaires à considérer pour le contrôle d'accès.
• le type de requête, c'est-à-dire l'action à réaliser. Le type de requête est principalement déterminé par l'appel système utilisé.
• la cible, c'est-à-dire l'objet sur lequel l'action est faite.

RSBAC récupère sa configuration pour déterminer si le sujet le droit d'effectuer ce type de requête sur cette cible, puis autorise ou rejette la requête. Les attributs qui autorisent la requête pour le sujet sont différents dans les différents modules de sécurité.

Les cibles sont divisées en plusieurs catégories, qui sont traitées différemment. Les principales sont :

• FILE pour les fichiers
• DIR pour les dossiers (ou répertoires)
• DEV pour les périphériques
• IPC pour les méthodes de communication inter-processus
• PROCESS pour les processus
• NETOBJ pour les connexions réseaux au sens large, en incluant aussi bien les communications via le protocole IP que celles avec Netlink

Les types de requête sont variés et vont de CLONE pour autoriser la copie d'un processus avec fork à MOUNT pour autoriser le montage d'un système de fichiers. Le même type de requête peut être utilisé par plusieurs appels système : CHANGE_OWNER s'applique lorsque l'on change le propriétaire d'un fichier ou répertoire avec chown, mais aussi celui d'un processus avec setuid. Aussi, plusieurs types de requête peuvent être utilisés par un même appel système, en particulier open peut demander READ_OPEN, WRITE_OPEN, READ_WRITE_OPEN, APPEND_OPEN, ou TRUNCATE selon la situation.

Modes

RSBAC fournit deux modes : le mode sécurisé et le mode relâché (softmode). Dans les deux modes, les requêtes des appels système sont évaluées. En mode sécurisé, la décision d'accès est appliquée telle quelle. En revanche, en mode relâché l'accès est toujours accordé même lorsque qu'un refus est renvoyé pour la décision d'accès. Le mode relâché est fourni pour pouvoir facilement tester le système et ne devrait pas être utilisé sur un système en production.

Module par rôles RC (Role Compatibility)

Quand ce module est utilisé, chaque processus a un rôle. Pour chaque rôle, il est possible de définir si le rôle a le droit de faire une requête spécifique sur une cible spécifique. L'accès est ensuite accordé selon les permissions définies.

Pour renforcer le contrôle d'accès, chaque catégorie de cible peut être divisée en types. Les types sont des groupes de cibles de même catégorie. Les objets FILE et DIR sont regroupés dans des types FD.

Par exemple, plusieurs types FD peuvent être définis : un premier peut être appliqué sur les répertoires et fichiers dans /etc, un deuxième pour ceux dans /usr/bin et /usr/sbin et un troisième pour tous les autres. Le même rôle peut ainsi avoir des permissions différentes sur ces trois types. Les droits dont chaque rôle disposent sur les différents types sont appelés « compatibilités de types » (type compatibilities).

Avec ces mécanismes, la granularité du contrôle est facilement ajustée pendant la configuration du système tout en ajoutant une couche d'abstraction.

En exécutant un nouveau programme, le processus prend soit le rôle de l'utilisateur qui l'exécute, soit celui défini dans un attribut du fichier exécuté. Ce choix peut être différent pour plusieurs programmes sur un même système.

Un processus a trois manières de changer son rôle courant :

• en exécutant un fichier pour lequel l'attribut de rôle est différent du rôle courant
• en changeant le propriétaire du processus courant avec un appel à setuid
• en utilisant un appel système spécifique à RSBAC

Les rôles qu'un rôle peut prendre avec l'appel système spécifique à RSBAC peuvent être restreints à la configuration. De tels rôles sont dits « compatibles » avec le second, ce qui donne le nom Role Compatibility à ce module.

Listes de contrôle d'accès (ACL)

Avec ce module, les droits sur chaque objet spécifique - comme un périphérique ou un fichier - sont directement accordés ou restreints. Les droits sont accordés aux utilisateurs ou à des groupes ACL d'utilisateurs (qui diffèrent des groupes Linux classiques). Des droits par défaut sont définis pour chaque catégorie de cible (FILE, IPC ...).

Autres modules

Le module MAC (mandatory access control) implémente une version du modèle de Bell-La Padula qui tente de mettre en place un système de sécurité multiniveau.

Le module UDF (userspace decision facility) délègue à un processus fonctionnant dans l'espace utilisateur (plutôt que des règles déjà définis dans l'espace noyau) la décision d'accès à un fichier. En particulier, il permet de faire de la recherche de virus à l'accès : quand un utilisateur veut accéder à un fichier, le processus UDF l'analyse et décline l'accès s'il estime que le fichier est malveillant.

D'autres modules ont des fonctionnalités qui sont plus éloignées du contrôle d'accès mais qui augmentent tout de même la sécurité du système.

Le module AUTH (authenticated user) restreint quels appels à setuid() sont autorisés pour les processus. C'est un module basique qui renforce les protections apportées par les autres modules.

Le module CAP (capabilities) permet de définir les capabilities Linux minimum et maximum pour les fichiers exécutables et les utilisateurs. En particulier, les pouvoirs maximums de l'utilisateur root peuvent être limités.

Le module JAIL confine un processus en restreignant ses accès sur le système.

Le module RES (resource control) définit pour des processus l'utilisation minimale et maximale de ressources systèmes telles que le temps de calcul, l'utilisation de la pile, ou le nombre de cœurs utilisés.

Le module FF (file flags) permet d'appliquer des attributs particuliers sur des fichiers pour définir certaines propriétés, comme l'impossibilité de les supprimer ou les renommer. Les mêmes fonctionnalités peuvent être configurées via les autres modules, mais celui-ci est plus simple à utiliser.

Fonctionnalités supplémentaires

RSBAC offre la possibilité d'ajouter son propre module avec des règles personnalisées via l'interface REG (registration), qui permet l'utilisation des mêmes structures de données que les autres modules pour des raisons de performance.

Le système UM (User Management) gère les utilisateurs et les groupes différemment que les fichiers classiques /etc/passwd, /etc/shadow et /etc/group. Il offre d'autres fonctionnalités comme des mots de passe à usage unique et peut remplacer entièrement le système traditionnel.

RSBAC peut contrôler l'accès aux connexions réseaux selon plusieurs critères, comme la famille d'adresse (par exemple un socket Unix ou un socket IPv4), la famille de protocole, l'adresse ou le port utilisé.

RSBAC fournit un certain niveau de séparation des privilèges : ses privilèges administratifs peuvent être séparés entre plusieurs utilisateurs ou rôles RC.

Système de contrôle d'accès

L'architecture système de RSBAC est basée sur le Generalized Framework for Access Control (GFAC) de Marshall Abrams et Leonard La Padula. Elle est aussi inspirée par un essai de La Padula où il décrit comment le GFAC peut être implémenté au sein du système d'exploitation Unix.

Elle sépare le contrôle d'accès en plusieurs composants :

• la fonction d'application d'accès (Access Enforcement Facility - AEF)
• la fonction de décision d'accès (Access Decision Facility - ADF)
• les règles de contrôle d'accès (Access Control Rules - ACR)
• les informations de contrôle d'accès (Access Control Information - ACI)

Les ACI décrivent l'état courant des objets et sujets dans le système d'exploitation. Les ACR sont les règles autorisant ou empêchant l'accès aux objets selon les attributs du sujet et de l'objet.

Quand un sujet souhaite accéder à un objet via un appel système, l'AEF est appelée. Elle envoie les informations du sujet et de l'objet à l'ADF, qui récupère des attributs supplémentaires dans les ACI et les règles d'accès dans les ACR.

L'ADF détermine si une requête est autorisée grâce aux informations récupérées et indique à l'AEF le résultat. Si nécessaire, l'AEF met à jour les attributs dans les ACI. Finalement, l'AEF autorise ou empêche l'accès à l'objet pour le sujet.

Pour que ce système d'accès fonctionne, il faut modifier tous les appels système (pertinents) avec des appels à l'AEF et définir une interface claire entre l'AEF et l'ADF. Les types de requête en sont une partie importante.

Stockage de la configuration

La configuration de RSBAC est stockée dans un répertoire /rsbac.dat à la racine de chaque système de fichiers. Il est la propriété de root et a un mode d'accès Unix 000 (personne ne peut lire, écrire ou exécuter quoi que ce soit). De plus, le noyau RSBAC interdit tout accès à ces répertoires. À l'intérieur de ces répertoires, la configuration est séparée en plusieurs fichiers sérialisés.

En interne, les fichiers et répertoires sont référencés par leurs inœuds, comme SELinux mais à la différence d'AppArmor qui utilise les chemins d'accès. Cette méthode empêche de contourner le contrôle d'accès via des liens physiques mais peut provoquer quelques difficultés lors de mises à jour.

Hooks dédiés

Pour interagir avec les structures du noyau, RSBAC utilise des hooks sur mesure. Ce n'est donc pas un Linux Security Module (LSM). C'est un choix délibéré du projet qui parmi d'autres raisons indique que les hooks des LSM ne couvrent pas toutes les fonctionnalités de RSBAC et qu'ils exposent des structures bas niveau du noyau, augmentant grandement sa surface d'attaque.

Configuration du noyau

La plupart des fonctionnalités de RSBAC peuvent être activées ou désactivées en configuration la compilation du noyau Linux. Cela permet de réduire l'impact sur les performances du noyau si seules les fonctionnalités nécessaires sont activées.

Configuration des règles d'accès

RSBAC est configuré par des commandes dans l'espace utilisateur. Des outils graphiques (environnement en mode texte) sont aussi fournis pour avoir une méthode visuelle pour configurer le système.

Il est possible de récupérer toute la configuration RSBAC courante d'un système avec une seule commande. Cette commande liste toutes les commandes qui devront être exécutées pour appliquer cette configuration sur un système encore non configuré.

$ rc_set_item ROLE 10 name "MonRole"

$ rc_set_item TYPE 20 type_fd_name "MonTypeFD"

$ rc_set_item -a ROLE 10 type_comp_fd 20 READ_OPEN READ CLOSE

$ attr_set_user RC $(id -u utilisateur1) rc_def_role 10
$ attr_set_file_dir RC DIR "/etc" rc_type_fd 20

Interface /proc/rsbac-info

RSBAC met en place un répertoire particulier dans le pseudo-système de fichiers /proc (procfs).

Il est utilisé pour partager des informations et statistiques. Quelques paramètres peuvent aussi être changés directement en écrivant dans le fichier /proc/rsbac-info/debug, par exemple pour basculer du mode sécurisé au mode relâché (ou inversement). Ces paramètres peuvent aussi être configurés via des arguments sur la ligne de commande du noyau.

Journalisation

Par défaut, RSBAC ne journalise que les demandes d'accès rejetées. Il est possible de changer ce comportement pour chaque catégorie de cible, pour journaliser à la fois les demandes accordées et rejetées, ou aucune des deux. Le journal de RSBAC est disponible dans le fichier /proc/rsbac-info/rmsg et dans le journal système. Une option permet d'enregistrer le journal sur une machine distante.

Articles connexes

• Informatique
• Noyau Linux
• Sécurité informatique
• Linux Security Modules
• SELinux
• AppArmor
• Grsecurity
• Access Control List
• Contrôle d'accès discrétionnaire
• Contrôle d'accès obligatoire

Liens externes

• Site officiel

• Portail de la sécurité des systèmes d'information
• Portail des logiciels libres
• Portail de Linux