Un système d'exploitation permet à plusieurs processus de se dérouler simultanément; il est donc indispensable de contrôler les privilèges de chacun et de savoir protéger les objets : tous les processus n'ont pas les mêmes droits et ceux-ci doivent être vérifiés avant tout usage.

La notion de protection englobe l'ensemble des méthodes qui définissent les règles d'utilisation de ces objets et qui garantissent qu'elles sont respectées. Unix définit un système de contrôle qui est employé dans toutes les circonstances. Cette notion, bien qu'existante sous Windows, est très mal employée. Ceci provient de l'histoire de ce système. DOS et Windows, jusqu'à la version 98 comprise, ignorait complètement la notion d'usager et de protection. Elle fut introduite dans NT, dans le système de fichiers NTFS (NT File System) mais les mauvaises habitudes étaient prises et très peu de logiciels ont été conçu pour être installés correctementy et fonctionner sans les privilèges de l'administrateur, c'est à dire le droit de faire n'importe quoi.

On peut interdire à un processus tout accès à un objet, en supprimant, pour lui uniquement , toute possibilité d'établir une liaison. L'objet devient donc inexistant et invisible pour ce processus. Les procédures d'accès permettent de vérifier, avant usage l'emploi que l'on va faire d'un objet. On peut ainsi contrôler si les manipulations envisagées sont en accord avec les opérations autorisées. Malheur à celui qui, dans sa programmation, ne prend pas soin de faire ces contrôles, car le processus s'arrétera alors de la façon la plus lamentable !

L'utilisation d'une procédure d'accès simplifie la mise en œuvre des contrôles puisqu'ils sont tous fait avant lancement du processus. Malheureusement cela n'est pas toujours possible car cette méthode interdit tout changement des chemins d'accès au cours de la vie du processus : concrètement cela signifie qu'il devient impossible d'ouvrir un fichier dynamiquement à l'intérieur d'un programme. Il est impossible que l'utilisateur, ou le processus lui-même, décident du nom des fichiers à manipuler au cours de l'exécution du processus puisque les assignations des liaisons ont dues être établies préalablement. C'est pourquoi le contrôle par procédure d'accès est utilisé de façon limitée dans les logiciels modernes.

Les contrôles doivent permettre de refuser à un processus utilisateur, sans privilège particulier, d'effectuer certaines opérations : par exemple un processus pourra consulter le contenu d'un fichier sans jamais pouvoir le modifier. Dans le cas le plus extrême il n'aura aucun indice lui permettant de soupçonner son existence et pour ce processus le fichier n'existera pas. Les contrôles sont complexes et il est difficile de vérifier leur qualité. L'un des grands jeux des pirates informatiques est de trouver les faiblesses des protections installées sur les systèmes visibles epuis l'Internet et de passer au travers. Ceci est une activité sévèrement punie par la loi.

Plusieurs processus peuvent posséder des droits identiques sur une sélection d'objets, ce qui permet de définir des classes de droit ou domaines Di. On peut dessiner des matrices de droits d'accès (fig. 4.4) où l'on représente suivant une ligne les droits des processus appartenant à un même domaine, chaque colonne correspondant à un objet. Comme les domaines sont eux-mêmes des objets ils apparaissent dans les lignes et dans les colonnes. La liste des droits possibles dépend de la nature de l'objet.

Par exemple on peut définir pour différents types d'objets :

• objet fichier: lire, écrire, exécuter. Ce dernier droit s'applique à un programme ou à un script (un script est un fichier de commandes en Unix, appelé aussi fichier batch sous Windows).
• objet périphérique: demander, réquisitionner, allouer, libérer un contrôleur de disque par exemple.
• objet domaine: changer de domaine, c'est à dire acquérir les droits d'un autre domaine, ou modifier les droits à l'intérieur d'un domaine...

La figure 4.4 en présente un exemple.

	fichier 1	fichier 2	disque	D1	D2	D3
D1	<r,w,x>	<r,w>	<alloc,droits>	<>	<chgt requis>	<appel>
D2	<r>	<r,x>	<demande,libère>	<appel>	<>	<>
D3	<>	<>	<>	<>	<>	<>

Figure 4.4 - Exemple de matrice de droits d'accès

<> signifie que l'objet considéré ne figure pas dans le contexte du domaine considéré : fichier 1 est ainsi invisible dans le contexte de D3.

Par définition un domaine ne peut se modifier lui-même : D1 peut appeler D3, c'est à dire se placer dans le contexte des droits de D3 (appel), D1 peut changer les droits de D2 (changement requis) mais pas les siens propres. Cette action n'est pas réciproque : D1 peut se placer dans le contexte de D3 mais ne pourra alors plus revenir dans son contexte initial. <r> signifie droit de lecture, <w> d'écriture, <x> d'exécuter suivant la terminologie Unix. Une colonne représente une liste d'accès sur un objet, une ligne une liste de capacité.

Une grosse difficulté, lorsqu'on veut sécuriser un système d'exploitation, est de s'assurer qu'un processus ne puisse acquérir des droits indus. Ainsi un processus P appartenant à D2 peut se placer dans le contexte D1. Il peut alors modifier fichier 1, ce qui lui était interdit auparavant. On peut imaginer des cas où, à partir d'un premier domaine de droits, en passant successivement par différents domaines Dj, on peut se retrouver dans la situation où le processus P acquerrait des privilèges indus. Il est très difficile de vérifier tous les moyens qu'un processus possède pour accéder aux droits d'un domaine.

La notion de droit ne prend de sens que si le propriétaire de l'objet, et éventuellement le groupe auquel il appartient, sont identifiés. Elle nécessite donc l'existence d'une procédure d'identification qui permette de s'assurer sérieusement de l'identité de la personne (ou du processus) utilisateur des objets. En début de session il faut fournir un identificatif puis un mot de passe, jamais affiché sur l'écran, personnel et confidentiel. Dans le cas de processus lancés directement par le système d'exploitation celui leur attribue un propriétaire donc une classe de droits.

Les objets indispensables au bon fonctionnement du système d'exploitation sont particulièrement protégés et sont souvent totalement invisibles pour les utilisateurs ordinaires. Ces mécanismes manquent dans dans les versions non professionnelles de Windows car le système de fichiers emploie FAT où ils ne sont pas protégés. Cette déficience devient dangereuse lorsqu'on veut partager des informations à travers un réseau. C'est pourquoi il est fortement conseillé d'employer les versions professionnelles en activant le système de fichiers NTFS. Malheureusement gérer des droits n'est pas simple et dépasse souvent l'amateur, c'est pourquoi ce mécanisme n'est souvent pas mis en oeuvre.

Les droits sous Unix

Les listes de droits possibles ne sont pas les mêmes suivant les systèmes d'exploitation. Unix distingue fondamentalement trois possibilités en ce qui concerne les fichiers :

• r ou droit de lecture. Représentation octale : 4.
• w ou droit d'écriture, de modifier et même d'effacer complètement le fichier. Représentation octale 2.
• x ou droit d'exécution. Ce droit ne prend de sens que pour un programme exécutable ou un script. D'autres systèmes ne différentient pas x et w. Pour un répertoire x signifie que l'on a le droit d'accéder aux objets qu'il contient mais sans pouvoir lister leur nom (droit r). Valeur octale 1.

Ces droits peuvent être attribués séparément au propriétaire du fichier (owner), à un groupe particulier d'utilisateurs (group) ou au public (other). Les systèmes Unix ne distinguent que le propriétaire, le groupe de l'utilisateurs et les autres personnes.

Les droits sont donc, pour chaque catégorie, définis par la combinaison des droits rwx ou la somme de leurs valeurs octales. Par exemple rw correspond à 6, rwx à 7...

Lorsqu'on consulte les caractéristiques d'un fichier par la commande ls -l on les retrouve sous la forme :

-rwxr-x--- 1 epelboin user 7430 jan 29 2006 tri
-rw-r---r-- 1 epelboin user 2172 jan 29 2006 tri.c
drwxr-x--- 2 epelboin systeme 4096 jan 29 2006 recherche

Le fichier tri.c (code source en langage C) est visible pour tous mais modifiable par son seul propriétaire. Il n'est pas nécessaire de lui positionner le droit x puisqu'il n'est pas exécutable. Il le faudrait s'il s'agissait d'un script.

tri, qui est un programme exécutable est visible et exécutable par mes partenaires qui appartiennent à mon groupe. Les autres personnes peuvent l'exécuter mais il me faudra leur fournir le chemin d'accès complet puisque le nom du fichier est invisible pour eux.

Le répertoire recherche doit posséder le droit x pour être traversé, c'est à dire que les fichiers et répertoires qu'il contient soient accessibles.

D'autres systèmes permettent une discrimination plus fine en enregistrant des noms de personnes et de groupes suivis des droits particuliers sur chaque objet.

Limites de la protection

Une protection totale est difficile à assurer. On peut oublier de protéger correctement certains objets ou même être obligé de les laisser partiellement visibles. Par exemple, dans Unix, le fichier des mots de passe, /etc/passwd, peut être lu par n'importe qui, du moins dans les systèmes conventionnels. Ils sont encryptés mais l'algorithme de cryptage est dans le domaine public. Il n'est pas réversible mais, muni d'un dictionnaire, on peut tenter de retrouver la chaîne de caractères encryptée qui apparaît dans le fichier passwd. Si on code son prénom en guise de mot de passe il ne faudra pas plus de quelques minutes à un pirate disposant des outils nécessaires pour le retrouver! Il ne faut pas néanmoins exagérer: une protection efficace est possible et il ne fautpas imaginer que les films de fiction deviennent aussi simplement réalité.

Les versions modernes d'Unix ont introduit un mécanisme de shadow password qui cache les mots de passe aux utilisateurs ordinaires mais cela ne sert évidemment à rien si on acquiert les droits de l'administrateur (root).

Il existe des situations moins évidentes: il peut arriver que l'on désire protéger un domaine D3 contre un domaine D1 mais, si D1 a des droits sur D2 et D2 sur D3 on ne peut pas se prémunir aisément contre des transitions interdites. On résout cette difficulté par des méthodes hiérarchiques: D1 a des droits sur D2 mais D1 est protégé contre D2. Ceci rend malheureusement difficile la coopération entre deux domaines distincts. On peut également imaginer des systèmes méfiants qui spécifient clairement les droits des autres domaines sur toute partie de leur information. Cependant lorsque la gestion des droits est dynamique des autorisations indues peuvent se propager.

---

Copyright Yves Epelboin, université P.M. Curie, 2000, MAJ 30 janvier, 2006