Une des bases de la sécurisation d'un système de fichier concerne les droits que l'on peut attribuer aux fichiers par utilisateur du système. Historiquement, Linux possède une gestion des droits héritée d'Unix, appelée UGO. En effet, dans une inode du système de fichier sont stockées plusieurs informations. Parmi celles-ci, on trouve les permissions associées à l'utilisateur propriétaire du fichier (User), au Groupe (Group) et aux Autres principaux du système (Others). Pour le vérifier, un simple appel à la commande ls permet d'accéder à ces droits :
[seb@localhost /]$ ls -ld opt/
drwxrwxr-x 7 root staff 4096 nov 23 21:21 opt
On applique donc des droits à un
fichier pour 3 entités différentes. L'utilisateur a
généralement les droits les moins restrictifs, puis le
groupe et ensuite les autres, avec des droits tels que la lecture
simple.
Néanmoins, 2 problèmes
apparaissent avec ce genre de gestion des droits. Premièrement,
dès que l'on souhaite appliquer des droits complexes à
un répertoire, l'administrateur doit
« jongler »
avec une gestion des groupes. Imaginons que l'on souhaite créer
un répertoire pour placer la base de données client de
notre entreprise.
[seb@localhost /]$ mkdir customers
[seb@localhost /]$ chown vero.engineers customers
[seb@localhost /]$ chmod 770 customers
Avec l'exemple ci-dessus, on a créé un répertoire de travail pour les données clientèles. Ce répertoire appartient à l'utilisateur vero, chef du service Statistiques & Analyses des données. Le groupe associé est celui des ingénieurs. Toute personne membre de ce groupe peut lire, parcourir et écrire dans ce répertoire. Maintenant, un stagiaire arrive et a pour mission de travailler sur une base de données contenue dans ce répertoire. Il lui faut donc la permission de lire, d'écrire et de parcourir ce répertoire. La solution serait de le rendre membre du groupe des ingénieurs. Mais ceci a pour conséquence qu'il aura aussi accès à tout les autres projets où travaillaient les ingénieurs. On arrive alors à une impasse qu'il est difficile de résoudre sans les ACL, c'est à dire les listes de contrôle d'accès.
Un autre problème courant concerne les masques de création de fichier. Il arrive souvent qu'un utilisateur place un fichier qui lui appartient dans le répertoire d'un collègue. Or le propriétaire du document est le seul a pouvoir gérer les droits de ce fichiers. Il polluera alors le compte de son collègue qui ne pourra pas l'effacer ou le déplacer s'il n'a pas les droits suffisants.
Il devient donc nécessaire d'utiliser un mécanisme d'attribution de droits avancés tel que les ACL. Nous allons donc ici détailler leur installation et quelques pistes permettant de travailler au mieux avec ce nouvel outil.
L'installation est différente selon la distribution et le noyau que vous utilisez. Dans les versions 2.4, il est nécessaire de patcher le noyau. Patcher le noyau consiste à ajouter le code source nécessaire pour accéder à des fonctionnalités non incluses dans le code source officiel du noyau. Appliquer un patch entraîne donc l'obligation de recompiler le noyau et ses modules.
La logique est, pour simplifier la suivante :
Je ne détaillerais pas ici les 2 premières étapes qui n'entrent pas dans le cadre de ce document.
Après avoir téléchargé les patchs sur le site http://acl.bestbits.at, la première étape consiste donc à décompresser les 2 archives dans le répertoire de source :
[seb@localhost /]$ cp
linux-a.b.cea-x.y.z.diff.gz /usr/src
[seb@localhost /]$ cp
linux-a.b.cacl-x.y.z.diff.gz /usr/src
[seb@localhost /]$ cd
/usr/src
[seb@localhost /]$ gunzip
linux-a.b.cea-x.y.z.diff.gz
[seb@localhost /]$ gunzip
linux-a.b.cacl-x.y.z.diff.gz
Par le biais de la commande patch, on applique alors les modifications au code source :
[seb@localhost /]$ patch -p1
<
linux-a.b.cea-x.y.z.diff
[seb@localhost /]$ patch -p1 <
linux-a.b.cacl-x.y.z.diff
A ce stade, les sources devraient avoir été modifiées. Configurons maintenant les options de compilation du noyau. La procédure est classique. Selon les habitudes, le lecteur pourra lancer la commande make menuconfig ou make xconfig après avoir éventuellement saisi un make oldconfig pour récupérer la configuration actuelle du noyau. Les options à valider se trouve dans la partie FileSystem :
POSIX Access
Control Lists,
Ext3 extended attributes (NEW),
Ext3
POSIX Access Control Lists,
Ext2 extended attributes
(NEW) and
Ext2 POSIX Access Control Lists
De la même façon, la
recompilation du noyau pourra se faire selon les habitudes du lecteur
et selon la distribution utilisée. Je recommande vivement
d'utiliser des commandes telles que rpm -b ou make kpkg sous Debian
pour créer une archive respectivement RPM ou Debian.
Pour le 2.6, la fonctionnalité
est déjà incluse dans le noyau.
Ensuite, il est nécessaire
d'installer les outils permettant de manipuler ces droits.
|
|
|
|
|
| First | Previous | Post comment | Next | Last |