2.3.1 Concepts de base pour le contrôle d’accès dans Linux
Sur Linux, le contrôle d’accès s’élabore conformément au modèle DAC. Effectivement, dans les systèmes d’exploitation Linux, un objet, qui peut être un fichier ou un processus, se rapporte à un propriétaire appelé Owner et est aussi combiné à un groupe appelé Owner Group. Le restant des utilisateurs appelés Others sont considérés dans la définition des droits d’accès sur un objet.
Excepté l’utilisateur suprême (root) qui administre totalement tous les objets du système, uniquement le Owner peut accéder et modifier ses objets ; sans compter qu’il est également le seul à pouvoir déléguer des droits d’accès au Owner Group et aux Others.[9]
Les droits d’accès donnés à un objet sont traduits par trois entités de trois caractères qui appartiennent à l’ensemble : {r, w, x, −}.
La première entité de trois caractères indique le droit d’accès du Owner, la deuxième de trois caractères traduit les droits d’accès du Owner Group et la troisième entité de caractères indique les droits donnés au Others . (Voir Figure 2.1). Dès lors on parvient à trois entités de trois caractères. Le premier caractère de chacune des entités accorde le droit de lecture s’il retourne "r", autrement il retourne "−" et le droit de lecture n’est pas accordé.
Le deuxième caractère de chacune des entités accorde le droit d’accès en écriture sur un objet s’il retourne "w" sinon il retourne "−" et le droit d’écriture n’est pas accordé.
Le troisième caractère d’une entité accorde l’autorisation d’exécuter un objet s’il retourne "x" sinon il retourne "−" et le droit d’exécuter n’est pas accordé".
En exécutant la commande ls -l , on a les droits d’accès des différents fichiers ainsi que le présente la figure 2.2.
Figure 2.2 – Droit d’accès Linux : Exemple.
Selon l’exemple, le premier caractère révèle la nature de l’objet. Le caractère d nous indique que la nature du fichier est un dossier, tandis que le caractère − quant à lui nous indique que la nature de l’objet est un fichier. Les caractères ci-après traduisent les droits d’accès
pour respectivement le Owner, Owner Group et Others. La valeur drwxr − xr − x signifie que le Owner a les droits de lecture, d’écriture et de "traversée"(c’est-à-dire qu’on peut voir les sous-dossiers que le dossier contient) ; le Owner Group et le Others ont le droit de lecture et de "traversée". Sous Linux, les droits d’accès sont modifiables le Owner où le root en utilisant la commande chmod.
Le bit setuid
Quand un utilisateur lance un programme, celui-ci s’exécute avec les droits de cet utilisateur. Mais souvent, on veut lancer une commande spéciale (en général réservé au super utilisateur) en tant que simple utilisateur. L’exemple le plus manifeste étant la commande passwd dont le chemin d’accès est /usr/bin/passwd qui est une commande root.
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 25036 2013-10-02 11:08 /usr/bin/passwd
En regardant les droits sur passwd, on s’aperçoit que ce fichier est affecté par le bit setuid : c’est-à-dire que lorsqu’un utilisateur lance la commande passwd, elle est lancée avec les droits du root, ainsi l’écriture pourra se faire dans le fichier /etc/passwd et l’utilisateur aura changé son mot de passe sans être root. Sans le setuid5, l’utilisateur n’aurait pas pu écrire dans le
fichier /etc/passwd.
setuid est un attribut de fichier spécial qui indique au système d’exécuter certains programmes sous un ID utilisateur spécifique.[36]
Il est à noter que la notion de setuid n’existe pas pour les répertoires. Le bit setgid
La théorie du setgid6 est le même que le setuid pour un fichier, mais assurément au niveau
des droits du groupe. Un exécutable affecté par le bit setgid peut donc être déclenché avec les droits du groupe auquel il se rapporte.
En revanche, le comportement change lorsqu’il s’agit d’un répertoire. Quand il s’agit d’un répertoire, tous les fichiers créés dans ce répertoire appartiennent au même groupe que le répertoire. Exemple : prenons le cas d’un répertoire contenant plusieurs utilisateurs qui tra- vaillent sur celui-ci pour un même projet, il est bon d’affecter le bit setgid au dossier, de cette manière, les fichiers mis en œuvre appartiendront tous au même groupe.
drwxrws--- 2 tux projet1 48 Jan 19 10:12 backup 5. setuid = Set User ID.
le s signifie que le bit setuid est défini pour l’autorisation du groupe. Le propriétaire du dossier backup et les membres du groupe projet1 peuvent accéder au dit dossier.
Le sticky bit
L’utilisation du bit collant (sticky bit) est différente dépendamment de s’il appartient à un fichier ou à un répertoire. S’il est assigné à un fichier, alors le fichier en question est chargé dans la mémoire vive pour éviter d’avoir à le recueillir du disque dur à chacune de ces utilisations . Si ce bit appartient à un répertoire, alors son but est d’empêcher les utilisateurs de supprimer leurs fichiers respectifs. Les exemples spécifiques sont entre autres les répertoires /tmp et /var/tmp.
drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp
le t indique que le sticky bit est attribué au répertoire /tmp, dont l’accès en écriture demeure possible par tous les utilisateurs, sans que ceux-ci se suppriment leurs fichiers.
2.3.2 Gestion des listes de contrôles d’accès sous Linux
La majorité de plusieurs développements du modèle de sécurité Linux demeurait des fonction- nalités du modèle d’accès discrétionnaire. Les groupes de recherche Unix, ont mis au point chacun leurs propres améliorations, souvent très semblables les unes aux autres, des travaux laborieux ont été consentis pour essayer de les standardiser.
Les ACL (listes de contrôle d’accès) POSIX pour Linux sont fondées sur la proposition première du standard POSIX [35]. Elles sont employées comme une avancée de la notion traditionnelle d’autorisation pour les objets système de fichiers. Les ACL donnent lieu à la mise en œuvre des autorisations plus aisément que le concept d’autorisation traditionnel.
Avantage des ACL
En général, trois entités d’autorisations sont spécifiées pour chacun des objets (fichier) sous Linux. Ces entités englobent les autorisations lire (r), écrire (w) et exécuter (x) pour chacun des trois types d’utilisateurs : le Owner, le group et les others. Par ailleurs, il est possible de définir les bits set user id et set group id comme nous l’avons vu plus haut.
Cette notion élémentaire est absolument adaptée dans une grande partie des cas pratiques. Toutefois, pour les scénarios plus délicats ou les applications avancées, les administrateurs système jadis étaient obligés d’adopter plusieurs moyens pour contourner les limitations du concept d’autorisation traditionnel.
Les ACL sont perçues comme une avancée de la notion traditionnelle d’autorisation d’accès aux fichiers. Elles donnent lieu à l’attribution de différentes autorisations à des utilisateurs ou à des groupes, même si ceux-ci ne se rapportent pas au propriétaire d’origine ou au groupe propriétaire. Les listes de contrôle d’accès sont une fonctionnalité du Kernel Linux et sont actuellement prises en charge par ReiserFS, Ext2, Ext3, JFS et XFS [36].
Les ACL donnent lieu à la réalisation de scénarios complexes sans implanter des modèles d’autorisation complexes au niveau de l’application.
Gestion des ACL
Le Tableau 2.1 affiche les six types possibles d’entrées ACL, chaque entrée spécifie les au- torisations d’un utilisateur ou d’un groupe d’utilisateurs. L’entrée propriétaire spécifie les autorisations de l’utilisateur propriétaire de l’objet. L’entrée groupe propriétaire spécifie les autorisations du groupe propriétaire de l’objet. Le super utilisateur quant à lui à la possibi- lité de modifier le propriétaire ou le groupe propriétaire à travers les commandes chown ou chgrp. À ce moment-là, les entrées du propriétaire et du groupe propriétaire font allusion au nouveau propriétaire et au nouveau groupe propriétaire.
Chacune des entrées (utilisateur nommé) spécifie les autorisations de l’utilisateur défini dans le champ de qualification de l’entrée. Uniquement les entrées d’utilisateur nommé et de groupe nommé ont un champ de qualification qui n’est pas vide. L’entrée autre spécifie les autorisa- tions du reste des utilisateurs (others).
Type Forme Textuelle
propriétaire user : :rwx utilisateur nommé user :name :rwx groupe propriétaire group : :rwx groupe nommé group :name :rwx masque mask : :rwx autre other : :rwx
Table 2.1 – Types d’entrées ACL [36].
L’entrée masque, a pour rôle de restreindre les autorisations accordées par les entrées utilisateur nommé, groupe nommé et groupe propriétaire en spécifiant, parmi ces entrées, les autorisations qui sont en cours et les autorisations masquées.
Quand des autorisations sont configurées dans l’une des entrées citées ainsi que dans le masque, elles sont en cours tandis que les autorisations incluses seulement dans le masque ou seulement dans l’entrée en question ne sont pas en cours, et ne sont pas accordées. L’ensemble des autorisations définies dans les entrées propriétaire et groupe propriétaire sont constamment en cours. L’exemple du Tableau2.2 explique ce processus.
Type d’entrée Forme textuelle Autorisations utilisateurs nommé user :emma :r-x r-x
masque mask :: rw− rw−
autorisations en cours r– Table 2.2 – Masquage des autorisations d’accès.
On compte deux classes basiques d’ACL :
— une ACL minimale, inclus seulement les entrées des types propriétaire, groupe proprié- taire et autre, qui se rapportent aux bits conventionnels d’autorisation pour les fichiers et les répertoires.
Figure 2.3 – ACL minimale.
— Une ACL étendue est beaucoup plus développée. Elle inclus une entrée masque et peut renfermer de multiples entrées de type utilisateur nommé et groupe nommé.
Figure 2.4 – ACL étendue.
Répertoire avec une ACL d’accès
Les autorisations d’accès de l’utilisateur et du groupe pour tous les types d’objets système de fichiers (fichiers et répertoires) sont déterminées au moyen des ACL d’accès. Avec getfacl et
setfacl sur la ligne de commande, on peut visualiser et modifier les ACL. L’utilisation de ces commandes est présentée dans l’exemplaire suivant.
Exemple : Avant de créer le répertoire LSI, utilisons la commande umask pour spécifier les autorisations d’accès qui seront masquées chaque fois qu’un objet est créé.
La commande umask 027, spécifie les autorisations par défaut en accordant au propriétaire tous les droits (0), en refusant au groupe le droit d’écrire (2) et en n’accordant aucun droit aux autres utilisateurs (7). En réalité,umask masque les bits d’autorisation correspondants ou les désactive.
mkdir LSIcrée le répertoire LSI avec les droits par défaut tels qu’ils sont spécifiés par umask. Employons ls -dl LSI pour s’assurer que tous les droits ont été attribués correctement. Voici le résultat de la commande :
drwxr-x--- ... memel avtac ... LSI
Avec getfacl LSI, examinons l’état initial de l’ACL. On obtient des informations comme :
# file: LSI # owner: memel # group: avtac user::rwx group::r-x other::---
Les trois premières lignes donnent la description du nom, du propriétaire et du groupe pro- priétaire du répertoire. Les trois lignes suivantes affichent les trois entrées ACL propriétaire, groupe propriétaire et autre. En effet, dans le cas de l’ACL minimal, la commande getfacl ne génère pas plus d’informations que la commande ls.
Modifions l’ACL pour attribuer des droits de lecture, d’écriture et d’exécution à l’utilisateur additionnel emmanuel et au groupe additionnel labo, de la façon suivante :
setfacl -m user:emmanuel:rwx,group:labo:rwx LSI
L’option -m demande à setfacl permet de modifier l’ACL existante. C’est un argument qui désigne les entrées ACL à modifier. La partie restante indique le nom du répertoire dans lequel ces modifications ont été apportées.
# file: LSI # owner: memel
# group: avtac user::rwx user:emmanuel:rwx group::r-x group:labo:rwx mask::rwx other::---
En plus des entrées lancées pour l’utilisateur emmanuel et le groupe labo, une entrée mask a été générée. Cette entrée de masque est spécifiée automatiquement afin que tous les droits entrent en vigueur.
setfacl dispose automatiquement les entrées mask aux nouveaux paramètres sauf si nous désactivions cette fonctionnalité avec -n.
mask détermine le maximum de droits d’accès en vigueur pour toutes les entrées de la classe de groupe.
Les bits d’autorisation de la classe de groupe indiqué par la commande "ls -dl LSI" conviennent maintenant à l’entrée mask.
drwxrwx---+ ... memel avtac ... LSI
La première colonne du résultat compte un signe + indiquant que cet élément possède une ACL étendue.
Dépendamment du résultat de la commande ls, les droits de l’entrée de masque comprennent l’accès en écriture. En général, de tels bits d’autorisation signifient que le groupe propriétaire (avtac) a aussi le droit d’écrire sur répertoire LSI. Toutefois, les droits d’accès en vigueur du groupe propriétaire coïncide à la partie commune avec les droits spécifiés pour le groupe propriétaire et le masque (r − x).
Modifions l’entrée du masque avec setfacl ou chmod. Par exemple, faisons chmod g-w LSI.
La commande ls -dl LSI donne le résultat suivant : drwxr-x---+ ... memel avtac ... LSI
getfacl LSIaffiche :
# file: LSI # owner: memel # group: avtac user::rwx
user:emmanuel:rwx # effective: r-x group::r-x
group:labo:rwx # effective: r-x mask::r-x
other::---
Une fois la commande chmod exécutée, pour supprimer le droit écrire des bits de la classe de groupe, le résultat de la commande ls est suffisant pour savoir que les bits de masque devront être modifiés en conséquence : le droit d’écrire est à nouveau restreint au propriétaire de LSI. Le résultat de getfacl soutient ce fait. Ce résultat inclut un commentaire pour toutes les entrées dans lesquelles les bits d’autorisation en vigueur ne coïncident pas aux autorisations d’origine, car elles sont filtrées dépendamment de l’entrée de masque. Les autorisations d’ori- gine peuvent être reconstituées en tout temps grâce à la commande chmod g+w LSI. Répertoire avec une ACL par défaut
Les répertoires ont la possibilité de disposer d’une ACL par défaut. Les ACL par défaut s’appliquent uniquement aux répertoires et déterminent les autorisations qu’un objet Système de fichiers hérite de son répertoire parent lors de sa création[36].
Il y a deux façons d’attribuer les permissions d’une ACL par défaut d’un répertoire aux fichiers et aux sous-répertoires qu’il renferme :
— Un sous-répertoire hérite de l’ACL par défaut du répertoire parent en tant qu’ACL par défaut et ACL d’accès.
— Un fichier hérite d’une ACL par défaut en tant qu’ACL d’accès.
L’ensemble des appels système qui définissent les objets système de fichiers utilisent un pa- ramètre mode qui spécifie les droits d’accès pour le nouvel objet Système de fichiers. Au cas où le répertoire parent ne possède pas une ACL par défaut, les bits d’autorisation définis par umask sont retranchés des droits remis par le paramètre mode, le résultat étant attribué au nouvel objet.
En admettant que le répertoire parent dispose d’une ACL par défaut, les bits d’autorisation attribués au nouvel objet se rapportent à la partie commune des autorisations du paramètre mode et à celles spécifiées dans l’ACL par défaut. umask n’est pas pris en compte dans cette circonstance.
Les exemples ci-après représentent les opérations essentielles des répertoires et des ACL par défaut :
1. Ajoutons une ACL par défaut au répertoire existant LSI par la commande suivante :
L’argument -d de la commande setfacl lui demande de faire les modifications suivantes (argu- ment -m) à l’ACL par défaut.
Examinons plus soigneusement la sortie de cette commande : getfacl LSI # file: LSI # owner: memel # group: avtac user::rwx user:emmanuel:rwx group::r-x group:labo:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:labo:r-x default:mask::r-x default:other::---
getfacl retourne l’ACL d’accès et l’ACL par défaut. L’ACL par défaut est composée de toutes les lignes débutant par default. Quoique nous ayons uniquement exécuté la commande setfacl avec une entrée pour le groupe labo de l’ACL par défaut, setfacl a de façon automatique copié toutes les autres entrées de l’ACL d’accès dans le but de créer une ACL par défaut valide. Les ACL par défaut n’ont pas d’effet imminent sur les droits d’accès. Elles sont fonctionnelles seulement quand des objets système de fichiers sont créés. Ces objets héritent des droits pro- venant seulement de l’ACL par défaut de leur répertoire parent.
2. À l’intérieur de l’exemple ci-après, utilisons la commande mkdir pour créer dans LSI un sous-répertoire sousLSI qui hérite de l’ACL par défaut.
mkdir LSI/sousLSI getfacl LSI/sousLSI # file: LSI/sousLSI # owner: memel # group: avtac user::rwx group::r-x
group:labo:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:labo:r-x default:mask::r-x default:other::---
Bien entendu, le nouveau répertoire sousLSI a les droits de l’ACL par défaut du répertoire parent. L’ACL d’accès de sousLSI est la réplique exacte de l’ACL par défaut de LSI. L’ACL par défaut que ce répertoire doit céder à ses objets sous-jacent est aussi identique.
3. À l’aide de la commande touch créons un fichier monfichier dans le répertoire LSI, en l’occurrence, touch LSI/monfichier.
La commande ls -l LSI/monfichier donnera ainsi en sortie :
-rw-r---+ ... memel avtac ... LSI/monfichier
L’affichage de getfacl LSI/monfichier est la suivante :
# file: LSI/monfichier # owner: memel # group: avtac user::rw- group::r-x # effective:r-- group:labo:r-x # effective:r-- mask::r-- other::---
la commande touch dispose d’un paramètre mode qui a la valeur 0666 lorsque les fichiers sont crées. La création des fichiers se fait donc avec les droits lire et écrire pour toutes les classes d’utilisateurs, pourvu qu’il n’existe pas une restriction en plus dans umask ou dans l’ACL par défaut .
Cette démarche renforce l’interaction correcte des applications, particulièrement des compi- lateurs, avec les ACL. A ce niveau on peut donc créer des fichiers ayant des droits d’accès restreint et les marquer par la suite comme exécutables.
2.3.3 SELinux
Security Enhanced Linux (SELinux) est l’implémentation d’un contrôle d’accès obligatoire (MAC). Il a été conçu pour répondre à une grande variété de besoins de sécurité, de l’uti- lisation générale, aux exigences des systèmes gouvernementaux et militaires exploitant des informations classifiées [39]. La sécurité du MAC est différente de celle du DAC à cause de la politique de sécurité qui y est administrée de manière centrale, et aussi que les utilisateurs n’ont aucun contrôle en ce qui concerne la politique de leurs ressources. Cette approche par- ticipe à contrôler les attaques qui exploitent des bogues ou des défauts de configuration dans les applications pour utilisateur.
Sous SELinux, on attribue aux objets tels les fichiers, des étiquettes ou labels. Toutes les ré- actions entre les ensembles liés à la sécurité sont retenues par LSM7 et données au module
SELinux, qui examine la politique de sécurité de façon à déterminer si l’opération en cours peut continuer. La politique de sécurité SELinux est loadée depuis la plateforme utilisateur, et est modifiable pour faire face à plusieurs objectifs de sécurité. Beaucoup de modèles de MAC passés détenaient une politique fixe, qui délimitait leur application dans un cadre d’informa- tique générale.
SELinux est installé sur plusieurs OS Linux et également activé par défaut sur tous les OS basés sur Fedora.
Implémentation de SE Linux
D’après [41], le code source de SELinux est inséré dans les noyaux de base fournis par Debian et les programmes standards issus de la famille Unix. Ainsi on peut facilement utiliser SELinux. La commande utilisée pour l’installation du paquetage et indispensable pour paramétrer une plateforme SELinux est :
aptitude install selinux-basics selinux-policy-default.
Le package selinux-policy-default comprend plusieurs de règles de base. Naturellement, ces règles limitent les accès que pour quelques services mis en évidence. Les sessions utilisateur n’étant pas limitées, il n’y a par conséquent peu de chance que SELinux empêche les opérations