|
 |
|
 |
|
Le "Compartemented Mode Workstation"
|
|
 |
|
 |
Pour respecter les recommandations de la classe de fonctionnalité F-B1, il faut appliquer certains mécanismes comme ceux
du CMW.
C.M.W. (Compartemented Mode Workstation)
Ce sigle fait référence à un mode de fonctionnement dans lequel toutes les informations sont labellisées par un niveau
de sécurité (system_low, public, restreint, confidentiel, secret, top secret,mais en pratique, cela est paramétrable
par l'utilisateur) et un ou plusieurs compartiments d'appartenance (projet A, dossiers X,..., on peut appartenir à
plusieurs compartiments). Les spécifications CMW ont été faites en partie par la N.S.A.
(National Security Agency) et Sun Microsystems.
Ces documents sont difficiles à obtenir (pas de retour de requêtes effectuées
chez SUN et la NSA). Toutefois, nous disposons de la documentation de Trusted Solaris qui est B1/CMW.
Dans un système CMW, toutes les informations sont labellisées. Tout objet portant des informations se retrouve donc
"teinté" par ses informations et prend, à priori, le niveau de sécurité de celles-ci. Un objet peut créer des
informations à son niveau et au-dessus, mais pas en dessous (problème de déclassification). Cette description de
fonctionnement s'appelle un "modèle formel de politique de sécurité". Il en existe plusieurs,
comme par exemple le modèle "Bell - La Padula"
En pratique, cela signifie que :
· Le système tourne à un certain niveau de sécurité. Ce niveau lui donne :
· Tout pouvoir pour manipuler les informations des utilisateurs, en pratique pour gérer le swap, permettre le scheduling,
etc. Cela ne donne cependant pas accès aux informations des utilisateurs, simplement à leur manipulation.
· Une protection contre les modifications intempestives d'utilisateurs ou logiciel, que cela soit le fait de bugs ou
de malversation. Exemple: tous les exécutables du système, ainsi que les fichiers de configuration, sont des fichiers
SYSTEM_LOW, pour que personne ne puisse écrire dedans (les utilisateurs sont au minimum au niveau PUBLIC :
Il ne peut pas "déclassifier" d'information au niveau SYSTEM_LOW). Par contre, les fichiers de logs sont au niveau
SYSTEM_HIGH : tout le monde peut écrire dedans, et personne ne peut les lire (information confidentielle).
· Un utilisateur se connecte avec un certain nombre de privilèges. Il choisit à sa connexion :
· Le projet sur lequel il souhaite travailler,
· Son niveau de sécurité auquel il souhaite travailler, s'il dispose de plusieurs niveaux. Les niveaux sont peut-être
fonction du projet choisi. Il peut peut-être choisir une fourchette de niveau,
· Aucun utilisateur n'a les pleins pouvoir sur un autre, à fortiori sur tous les autres. En conséquence : l'administrateur
système doit gérer sa machine mais pas voir le contenu des fichiers utilisateurs (ou de la RAM qu'ils utilisent).
L'officier de sécurité sert à gérer les droits. En pratique, l'administration de la sécurité s'effectue avec ses deux
personnes qui disposent de droits spécifiques.
· Les utilisateurs peuvent posséder des droits particuliers
nécessaires au fonctionnement correct du système. Ces droits
leur permettent d'outrepasser certaines contraintes de la politique de sécurité. Ainsi, un officier de sécurité
particulier peut se voir octroyer le droit de déclassifier des informations, c'est à dire passer une information de
l'état CONFIDENTIEL à l'état PUBLIC par exemple. Ce genre d'action est bien évidemment audité. Un exécutable particulier
peut avoir le droit d'outrepasser la politique de contrôle d'accès mandataire (les niveaux de sécurité) afin de pouvoir
effectuer des sauvegardes des informations. Ces sauvegardes doivent contenir les informations de sécurité des fichiers,
évidemment. Programmes tar, cpio, etc... à refaire. Certains droits ne doivent pas pouvoir être cumulés sur une seule
personne. Exemple, la création et l'autorisation d'un compte utilisateur ne doivent pas pouvoir être donnés à un seul et
même compte. L'administrateur créé le compte, met en place les quotas, l'environnement, et l'officier de sécurité lui
donne ses droits.
· Il doit exister un chemin de confiance
("Trusted Path") entre l'utilisateur et la machine / le système d'exploitation.
C'est une obligation du niveau B1. Ce TP permet à l'utilisateur de donner des informations relatives à la machine, en
étant sur qu'il discute bien avec le système et pas avec un programme qui tenterait de se faire passer pour lui. L'accès
au TP s'effectue généralement par une combinaison de touche (Ctrl-Alt-Del sous Windows NT par exemple) ou sur certaines
zones de l'écran infalsifiables par les utilisateurs (zone de dessin/d'affichage inaccessible aux logiciels par exemple).
· En ce qui concerne les informations labellisées, il faut tenir compte de tout. Voici une liste, probablement non
exhaustive :
· Chaque fichier sur le disque possède ses informations de sécurité (propriétaire, niveau, compartiments),
· Chaque espace mémoire possède ses informations (idem fichier, plus processus propriétaire),
· Tout échange d'information est forcément contrôlé par le noyau : sur disque via le système de fichier, en mémoire
(partagée) également, et par des sémaphores et signaux : labels à mettre en place. Un processus ne peut signaler un
autre qu'à la condition qu'ils respectent des règles de sécurité définies.
· Tout accès réseau implique deux choses :
· Soit la connexion provient d'une machine de confiance (dialogue sécurisé entre les deux) auquel cas on conserve les
informations de sécurité ;
· Soit la machine est inconnue auquel cas on lui applique systématiquement un label de sécurité faible (NETWORK, juste
au-dessus de SYSTEM_LOW par exemple). Se pose alors le problème du choix du compartiment auquel appartient le paquet.
Il peut être décidé qu'un paquet "vierge" prend la teinte du premier processus qui le touche (a priori celui qui a reçu
le paquet).
· Tout processus possède ses informations
(idem fichier, plus niveau et compartiment courant suivant les fichiers
accédés, plus droits d'origine et droits courant). Un logiciel peut se voir attribué par le système des droits
particuliers lorsqu'il s'exécute (exemple : programme de sauvegarde qui outrepasse l'accès mandataire). Un tel programme
doit provoquer ses droits.
Un point intéressant des systèmes CMW est justement le fonctionnement en compartiments. Un logiciel pour lequel on
n'a aucune confiance peut être exécuté sans crainte dans un compartiment qui est propre. Si jamais le logiciel possède
une faille, tout ce à quoi il aura accès (ou donnera accès) sera son propre compartiment qui, idéalement, ne contiendra
que lui : pas de shell, pas de visibilité sur le système, etc., cela signifie également qu'un programme non prévu pour
un système CMW doit, à priori, pouvoir tourner tel quel sur un tel système. Si le logiciel effectue des opérations
particulières (écouter sur un port privilégié par exemple), alors il doit pouvoir être possible de lui donner les droits
nécessaires à le faire.
Exemples de systèmes CMW :
Trusted Solaris
Sco Unix
HP-UX
|
|
