Product SiteDocumentation Site

4.17. Limites et contrôle des systèmes de fichiers

4.17.1. Utilisation de quotas

Avoir une bonne politique relative aux quotas est important, vu qu'elle empêche les utilisateurs de remplir les disques durs.
Vous pouvez utiliser deux systèmes de quotas différents: les quotas utilisateur et les quotas groupe. Comme vous l'avez probablement deviné, les quotas utilisateur limitent la quantité d'espace qu'un utilisateur peut avoir, les quotas groupe quant à eux font la même chose pour les groupes. Retenez cela quand vous calculerez les tailles des quotas.
Il y a quelques points importants auxquels il faut penser dans la mise en place d'un système de quotas:
  • garder les quotas suffisamment petits, ainsi les utilisateurs ne dévoreront pas l'espace disque ;
  • garder les quotas suffisamment grands, ainsi les utilisateurs ne se plaindront pas et leur quota de courrier leur permettra d'accepter des courriers pendant une longue période ;
  • utiliser des quotas sur tous les espaces accessibles en écriture par les utilisateurs, aussi bien sur /home que /tmp.
Tous les répertoires et partitions auxquels les utilisateurs ont accès en écriture complet devraient avoir les quotas activés. Recherchez ces partitions et répertoires et calculez une taille adaptée qui combine disponibilité et sécurité.
Bon, maintenant vous désirez utiliser les quotas. Avant tout, vous avez besoin de vérifier si vous avez activé la prise en charge des quotas dans le noyau. Si non, vous devrez le recompiler. Après cela, contrôlez si le paquet quota est installé. Si non, vous en aurez également besoin.
L'activation des quotas pour des systèmes de fichiers différents est aussi facile que la modification du paramètre defaults en defaults,usrquota dans le fichier /etc/fstab. Si vous avez besoin des quotas par groupe, remplacez usrquota par grpquota. Vous pouvez également utiliser les deux. Ensuite, créez des fichiers vides quota.user et quota.group à la racine du système de fichiers sur lequel vous voulez utiliser les quotas:
touch
/home/quota.user /home/quota.group
pour un système de fichiers /home)
Redémarrez quota en faisant:
/etc/init.d/quota stop;/etc/init.d/quota
        start
Maintenant les quotas devraient être en fonction et leurs tailles peuvent être configurées.
L'édition de quotas pour un utilisateur spécifique peut être réalisée en faisant
edquota -u <user>
. Les quotas par groupes peuvent être modifiés avec
edquota -g <group>
. Ensuite, paramétrez les quotas soft et hard ou les quotas pour inœuds selon vos besoins.
Pour plus d'informations concernant les quotas, consultez la page de manuel de la commande quota et le quota mini-howto (/usr/share/doc/HOWTO/fr-html/Quota.html). Vous pouvez également vouloir étudier pam_limits.so.

4.17.2. Les attributs spécifiques du système de fichiers ext2 (chattr/lsattr)

En plus des permissions standards UNIX, les systèmes de fichiers ext2 et ext3 offrent un ensemble d'attributs spécifiques qui donnent plus de contrôle sur les fichiers du système. À la différence des permissions de base, ces attributs ne sont pas affichés par la commande standard ls -l, ni changés par la commande chmod et vous avez besoin de deux autres utilitaires, lsattr et chattr (du paquet e2fsprogs) pour les gérer. Notez que cela veut dire que ces attributs ne sont habituellement pas enregistrés quand vous sauvegardez le système, donc si vous modifiez l'un d'entre eux, il peut être utile d'enregistrer les commandes chattr successives dans un script pour pouvoir les repositionner plus tard si vous avez à récupérer une sauvegarde.
Parmi tous les attributs disponibles, les deux plus importants pour améliorer la sécurité sont référencés par les lettres «i» et «a» et ils ne peuvent être positionnés (ou enlevés) que par le superutilisateur:
  • l'attribut «i» (inchangeable, «immutable»): un fichier ayant cet attribut ne peut-être ni modifié ni effacé ou encore renommé et aucun lien ne peut le référencer, même par le superutilisateur ;
  • l'attribut «a» (ajout, «append»): cet attribut a le même effet que l'attribut «immutable», excepté que vous pouvez encore ouvrir le fichier en mode ajout. Cela veut dire que vous pouvez encore ajouter plus de contenu au fichier, mais qu'il est impossible de modifier un contenu précédent. Cet attribut est particulièrement utile pour les fichiers de journalisation stockés dans /var/log/, bien que vous devez considérer qu'ils sont parfois déplacés à cause des scripts d'archivage.
Ces attributs peuvent également être positionnés pour les répertoires, dans ce cas, le droit de modifier le contenu de la liste d'un répertoire est refusé (par exemple, renommer ou supprimer un fichier, etc.) Quand il est appliqué à un répertoire, l'attribut d'ajout ne permet que la création de fichiers.
Il est aisé de voir que l'attribut «a» améliore la sécurité, en donnant aux programmes qui ne sont pas exécutés par le superutilisateur, la possibilité d'ajouter des données à un fichier sans pouvoir modifier son précédent contenu. D'un autre côté, l'attribut «i» semble moins intéressant: après tout, le superutilisateur peut déjà utiliser les permissions standards UNIX pour restreindre l'accès à un fichier et un intrus qui aurait accès au compte superutilisateur peut toujours utiliser le programme chattr pour supprimer l'attribut. Un tel intrus peut tout d'abord être perplexe quand il se rendra compte qu'il ne peut pas supprimer un fichier, mais vous ne devriez pas supposer qu'il est aveugle — après tout, il est entré dans le système! Certains manuels (y compris une précédente version de ce document) suggèrent de supprimer simplement les programmes chattr et lsattr du système pour améliorer la sécurité, mais ce genre de stratégie, aussi connu comme «sécurité par l'obscurité», doit être absolument évitée, car elle donne un sentiment trompeur de sécurité.
Une façon sûre de résoudre ce problème est d'utiliser les fonctionnalités du noyau Linux, comme décrit dans Section 10.4.2.1, « Défense proactive ». La fonctionnalité intéressante est appelée ici CAP_LINUX_IMMUTABLE: si vous la supprimez de l'ensemble des fonctionnalités (en utilisant par exemple la commande lcap CAP_LINUX_IMMUTABLE), il ne sera plus possible de modifier les attributs « a » ou « i » sur le système, même pour le superutilisateur ! Une stratégie complète serait alors la suivante :
  • positionner les attributs «a» et «i» sur tous les fichiers voulus;
  • ajouter la commande lcap CAP_LINUX_IMMUTABLE (ainsi que lcap CAP_SYS_MODULE, comme suggéré dans Section 10.4.2.1, « Défense proactive ») à l'un des scripts de démarrage ;
  • positionner l'attribut «i» sur ce script et les autres fichiers de démarrage, ainsi que sur le binaire lcap lui-même;
  • exécuter la commande ci-dessus vous-même (ou réamorcer le système pour vous assurer que tout fonctionne comme prévu).
Maintenant que la fonctionnalité a été enlevée du système, un intrus ne peut plus changer aucun attribut des fichiers protégés et donc, il ne peut pas changer ou supprimer les fichiers. S'il force la machine à redémarrer (ce qui est la seule façon de récupérer le jeu de fonctionnalités), cela sera facile à détecter et la fonctionnalité sera de toute façon enlevée à nouveau dès que le redémarrage du système. La seule façon de changer un fichier protégé serait de réamorcer le système en mode utilisateur seul (single-user mode) ou d'utiliser une autre image d'amorçage, deux opérations qui nécessitent un accès physique à la machine!

4.17.3. Vérifier l'intégrité des systèmes de fichiers

Êtes-vous sûr que le /bin/login présent sur le disque dur est le même que celui que vous aviez installé il y a de cela quelques mois? Que faire si c'est une version piratée, qui enregistre les mots de passe entrés dans un fichier caché ou les envoie en clair sur Internet?
La seule méthode pour avoir un semblant de protection est de vérifier vos fichiers tous les heures/jours/mois (je préfère quotidiennement) en comparant l'actuel et l'ancien md5sum de ce fichier. Deux fichiers ne peuvent avoir le même md5sum (le MD5 est basé sur 128 bits, ainsi la chance que deux fichiers différents aient le même md5sum est approximativement de un sur 3.4e3803), donc de ce côté tout est bon, à moins que quelqu'un ait piraté également l'algorithme qui crée les md5sums sur cette machine. C'est extrêmement difficile et très improbable. Vous devriez vraiment prendre en compte que la vérification de vos binaires est très importante étant donné que c'est un moyen facile de reconnaître des changements sur vos binaires.
Les outils couramment utilisés pour cela sont sxid, aide (Advanced Intrusion Detection Environment), tripwire, integrit et samhain. Installer debsums vous aidera également à vérifier l'intégrité du système de fichiers en comparant le md5sum de chaque fichier avec celui utilisé dans l'archive des paquets Debian. Mais faites attention: ces fichiers peuvent facilement être modifiés par un attaquant et tous les paquets ne fournissent pas de listes de md5sum pour les binaires qu'ils fournissent. Pour plus d'informations, veuillez consulter Section 10.2, « Tests d'intégrité périodiques » et Section 4.19, « Prendre un instantané («snapshot») du système ».
Vous pouvez vouloir utiliser locate pour indexer le système de fichiers en entier; si vous faites cela, envisagez les implications de cette action. Le paquet findutils de Debian contient locate qui s'exécute en tant qu'utilisateur nobody, ainsi, il indexe les fichiers qui sont visibles à tous les utilisateurs. Cependant, si vous changez son comportement, vous rendrez les emplacements de tous les fichiers visibles à tous les utilisateurs. Si vous voulez indexer tout le système de fichiers (pas les parties que l'utilisateur nobody peut voir), vous pouvez remplacer locate par slocate. slocate est étiqueté comme une version améliorée au niveau sécurité de GNU locate, mais il fournit en fait une fonctionnalité de localisation de fichier supplémentaire. Quand il utilise slocate, l'utilisateur ne peut voir que les fichiers auxquels il a vraiment accès et vous pouvez exclure tout fichier ou répertoire du système. Le paquet slocate exécute le processus de mise à jour avec des privilèges augmentés par rapport à locate et il indexe tous les fichiers. Les utilisateurs peuvent alors rechercher rapidement tout fichier qu'ils peuvent voir. slocate ne leur laisse pas voir les nouveaux fichiers; il filtre la sortie selon l'UID.
Vous pourriez utiliser bsign ou elfsign. elfsign fournit un utilitaire pour ajouter une signature numérique à un binaire ELF et un autre pour vérifier cette signature. L'actuelle implémentation utilise PKI pour signer la somme de contrôle du binaire. L'avantage de faire cela est que ceux qui le veulent peuvent déterminer si un binaire a été modifié et qui l'a créé. bsign utilise GPG, elfsign utilise les certificats PKI (X.509, OpenSSL).

4.17.4. Mise en place de la vérification setuid

Le paquet Debian checksecurity fournit une tâche cron qui s'exécute tous les jours dans /etc/cron.daily/checksecurity [38]. Cette tâche cron exécutera le script /usr/sbin/checksecurity qui sauvegardera les renseignements sur les modifications.
Le comportement par défaut est de ne pas envoyer cette information au superutilisateur mais à la place de garder une copie quotidienne des modifications dans /var/log/setuid.changes. Vous devrez positionner la variable MAILTO (dans /etc/checksecurity.conf) à «root» pour que ces renseignements lui soient envoyés. Consultez checksecurity(8) pour plus d'informations sur la configuration.


[38] Dans les versions précédentes, checksecurity était intégré dans cron et le fichier était /etc/cron.daily/standard.