Chapitre 6. Utilisation de la sécurité multiniveaux (MLS)
La politique de sécurité multiniveaux (MLS) utilise le site levels, tel qu'il a été conçu à l'origine par la communauté de la défense américaine. MLS répond à un ensemble très étroit d'exigences de sécurité basées sur la gestion de l'information dans des environnements rigoureusement contrôlés tels que l'armée.
L'utilisation de MLS est complexe et ne correspond pas bien aux scénarios d'utilisation généraux.
6.1. Sécurité multiniveaux (MLS)
La technologie MLS (Multi-Level Security) permet de classer les données de manière hiérarchique en utilisant des niveaux de sécurité de l'information, par exemple :
- [le plus bas] Non classé
- [bas] Confidentiel
- [haut] Secret
- [le plus haut] Top secret
Par défaut, la politique SELinux de MLS utilise 16 niveaux de sensibilité :
-
s0est le moins sensible. -
s15est le plus sensible.
Le MLS utilise une terminologie spécifique pour aborder les niveaux de sensibilité :
- Les utilisateurs et les processus sont appelés subjects, dont le niveau de sensibilité est appelé clearance.
- Les fichiers, dispositifs et autres composants passifs du système sont appelés objects, dont le niveau de sensibilité est appelé classification.
Pour mettre en œuvre la MLS, SELinux utilise le modèle Bell-La Padula Model (BLP). Ce modèle spécifie comment l'information peut circuler dans le système en fonction des étiquettes attachées à chaque sujet et à chaque objet.
Le principe de base du BLP est "No read up, no write down.". Cela signifie que les utilisateurs ne peuvent lire que les fichiers dont le niveau de sensibilité est inférieur ou égal au leur, et que les données ne peuvent circuler que des niveaux inférieurs vers les niveaux supérieurs, et jamais l'inverse.
La politique SELinux MLS, qui est la mise en œuvre de MLS sur RHEL, applique un principe modifié appelé Bell-La Padula with write equality. Cela signifie que les utilisateurs peuvent lire des fichiers à leur propre niveau de sensibilité et à un niveau inférieur, mais qu'ils ne peuvent écrire qu'à leur propre niveau. Cela empêche, par exemple, les utilisateurs à faible habilitation d'écrire du contenu dans des fichiers top secret.
Par exemple, par défaut, un utilisateur ayant le niveau d'habilitation s2:
-
Peut lire les fichiers avec les niveaux de sensibilité
s0,s1, ets2. -
Impossible de lire les fichiers dont le niveau de sensibilité est égal ou supérieur à
s3. -
Peut modifier des fichiers avec un niveau de sensibilité d'exactement
s2. -
Impossible de modifier des fichiers dont le niveau de sensibilité est différent de
s2.
Les administrateurs de sécurité peuvent adapter ce comportement en modifiant la politique SELinux du système. Par exemple, ils peuvent autoriser les utilisateurs à modifier des fichiers à des niveaux inférieurs, ce qui augmente le niveau de sensibilité du fichier en fonction du niveau d'autorisation de l'utilisateur.
Dans la pratique, les utilisateurs se voient généralement attribuer une série de niveaux d'autorisation, par exemple s1-s2. Un utilisateur peut lire des fichiers dont le niveau de sensibilité est inférieur au niveau maximal de l'utilisateur, et écrire dans tous les fichiers situés dans cette fourchette.
Par exemple, par défaut, un utilisateur ayant une plage d'autorisation s1-s2:
-
Peut lire des fichiers avec les niveaux de sensibilité
s0ets1. -
Impossible de lire les fichiers dont le niveau de sensibilité est égal ou supérieur à
s2. -
Peut modifier les fichiers avec le niveau de sensibilité
s1. -
Impossible de modifier des fichiers dont le niveau de sensibilité est différent de
s1. -
Peut modifier son propre niveau d'habilitation à
s2.
Le contexte de sécurité d'un utilisateur non privilégié dans un environnement MLS est, par exemple, le suivant :
user_u:user_r:user_t:s1
Où ?
user_u- est l'utilisateur SELinux.
user_r- est le rôle SELinux.
user_t- est le type SELinux.
s1- est la gamme des niveaux de sensibilité MLS.
Le système combine toujours les règles d'accès MLS avec les autorisations classiques d'accès aux fichiers. Par exemple, si un utilisateur ayant un niveau de sécurité "Secret" utilise le contrôle d'accès discrétionnaire (DAC) pour bloquer l'accès à un fichier par d'autres utilisateurs, même les utilisateurs "Top Secret" ne peuvent pas accéder à ce fichier. Un niveau de sécurité élevé ne permet pas automatiquement à un utilisateur de parcourir l'ensemble du système de fichiers.
Les utilisateurs disposant d'une habilitation de haut niveau n'acquièrent pas automatiquement des droits administratifs sur les systèmes à plusieurs niveaux. Bien qu'ils puissent avoir accès à toutes les informations sensibles du système, ce n'est pas la même chose que d'avoir des droits administratifs.
En outre, les droits administratifs ne donnent pas accès aux informations sensibles. Par exemple, même si une personne se connecte en tant que root, elle ne peut toujours pas lire les informations top secrètes.
Vous pouvez ajuster davantage l'accès au sein d'un système MLS en utilisant des catégories. Avec la sécurité multi-catégories (MCS), vous pouvez définir des catégories telles que des projets ou des départements, et les utilisateurs ne seront autorisés à accéder qu'aux fichiers des catégories auxquelles ils sont affectés. Pour plus d'informations, voir Utilisation de la sécurité multi-catégories (MCS) pour la confidentialité des données.
