Une erreur à corriger, une suggestion à faire, une contribution à apporter ? N'hésitez-plus ! Just write it!

Chapitre 14 Permissions

14.1 Les bases

Un grand classique parmi les questions sur la liste est « comment faire pour que tout le monde puisse se connecter à Internet, et pas seulement root? ». Une variante est « que tout le monde puisse utiliser la carte son ». Toutes ces questions ont le même genre de réponse sous Debian : on met les utilisateurs habilités à faire telle ou telle chose dans tel ou tel groupe. Mais avant d'aller plus loin, voyons un peu mieux ce que sont les permissions, et leur utilité.

14.1.1 Présentation du problème

Les permissions ne sont pas là seulement pour vous empêcher de faire ce que vous voulez (seul root peut utiliser le modem, c'est pas juste...) mais aussi pour :

Éviter les fausses manipulations
Garantir aux utilisateurs un minimum de confidentialité

Sous Unix, la plupart des périphériques sont vus sous forme de fichiers spéciaux placés dans le répertoire /dev (la souris, le disque dur, les partitions de chaque disque, le modem, etc). Qui a accès en lecture et écriture à l'un de ces fichiers contrôle le périphérique qui lui est associé sans aucune autre forme de sécurité.

Accorder un privilège est un acte qui doit être réfléchi. Il faut partir du principe que lorsque quelqu'un possède un privilège quelconque, un jour ou l'autre, ce droit sera utilisé d'au moins l'une des trois manières suivantes :

Intention de nuire
Bug dans un programme
Erreur de frappe

Certains périphériques sont évidemment plus sensibles que d'autres :

Donner des droits sur les disques, c'est courir à la catastrophe
Donner des droits sur une carte son semble anodin. Et pourtant, sur une machine multi-utilisateurs, Cela donne la possibilité d'espionner ce qui se dit à proximité du micro s'il y en a un (OK, je suis paranoïaque).
Donner des droits sur un lecteur de disquettes semble raisonnable, bien que sur une machine multi-utilisateurs on court le risque que quelqu'un efface les fichiers d'un camarade (peu probable je l'avoue ; OK, je suis paranoïaque).
Donner des droits sur un lecteur de CD me semble sans risques (et pourtant, je suis paranoïaque :).

14.1.2 La solution Debian

La philosophie Debian consiste à créer un grand nombre de groupes, un par catégorie de matériel. Dans /dev , chaque périphérique appartient à un de ces groupes, suivant sa catégorie.

À partir de là, il est facile de contrôler qui a le droit de faire quoi. Pour qu'un utilisateur ait le droit de se servir pleinement d'un lecteur de disquettes, c'est-à-dire non seulement de monter une disquette, mais aussi de la formater, il suffit de l'ajouter dans le groupe floppy (en fait monter une disquette ne nécessite absolument pas d'avoir des droits sur le lecteur de disquette. Aussi bizarre que ça puisse paraître à première vue, il faut des privilèges logiciels et non matériels).

Les groupes ont une autre utilité. Ils permettent également de contrôler certains aspects purement logiciels du système. Qui a le droit de lire tel ou tel fichier, ou qui a le droit de faire telle ou telle action.

14.2 Utiliser les groupes pour définir les permissions

14.2.1 Les différents groupes

Voici une liste de groupes, sans doute non exhaustive, accompagnés des privilèges qu'ils donnent (auxquels j'ai pensé):

adm : Ce groupe ne donne que des privilèges logiciels.

Le fait d'appartenir à ce groupe, permet la lecture de bon nombre de fichiers de log (notamment /var/tmp/btmp ) dans lesquels on trouve des choses intéressantes (comme des mots de passe en clair, mais c'est rare).

L'utilité majeure de ce groupe est de pouvoir lire les messages systèmes avec xconsole. Il faut ensuite lancer :
```
%
  
xconsole -file /dev/xconsole  -geometry 736x77+20+209
```
Ou du moins, c'est vrai sur ma machine. Il semble que ce ne soit pas vrai avec certaines distributions plus anciennes de Debian.

De fait, seul les administrateurs devraient appartenir à ce groupe.
audio : utiliser la carte son
floppy : Utiliser la disquette en «raw device» (sans système de fichier), ce qui permet de :
- formater les disquettes
- voir (dumper) les informations se trouvant sur une disquette sans utiliser les protections du système de fichier s'y trouvant.
- corrompre de la même manière les informations se trouvant sur une disquette.
- utiliser la disquette comme une bande magnétique pour archivage.
  
  tar cf /dev/fd0 <mondir>
- utiliser le paquet mtools pour accéder à un système de fichier FAT (dos).
dip : se connecter à Internet avec un modem. Ce groupe ne contrôle aucun matériel. Il donne uniquement accès à certains fichiers utilisés pour mettre en oeuvre la connexion IP.

dialout : utiliser directement un tty (port série), ce qui donne la possibilité d'utiliser un modem ou tout autre matériel qui y est connecté.

Attention : ça n'a rien à voir avec le groupe dip , ici on ne parle que de pouvoir causer à un port série, sûrement pas de mettre en oeuvre un liaison IP sur une telle ligne (ce qui nécessite des privilèges logiciels énormes).

(FIXME) Chez moi, getty change les permissions des consoles virtuelles dont il a la charge. Ces consoles appartiennent alors au groupe dialout . Je ne connais pas l'impact que cela peut avoir sur la sécurité.

disk : Utiliser le disque en «raw device» (sans système de fichier), ce qui permet de :
- formater les disques
- partitionner les disques
- voir (dumper) les informations se trouvant sur un disque sans utiliser les protections du système de fichier s'y trouvant.
- corrompre de la même manière les informations se trouvant sur un disque.
- utiliser le disque comme une bande magnétique pour archivage
- utiliser le paquet mtools pour accéder à un système de fichier FAT.
L'utilisation de ce groupe est à proscrire pour des raisons évidentes de stabilité, de sécurité, et de confidentialité.
cdrom : utiliser pleinement le lecteur de cdrom. (jouer des CD audio, éjecter le CD, etc...
tape : utiliser le bandes magnétiques c'est à dire lire, rembobiner, éjecter, se positionner, écrire, éventuellement initialiser ou formater (ou une action équivalente).

14.2.2 Ajouter un utilisateur dans un groupe

sous root, lancer la commande

%
  
  # adduser <nom de l'utilisateur> <nom du groupe>

Cette commande ne prend effet qu'après que l'utilisateur se soit déloggé puis reloggé.

14.2.3 Vérifier à quoi un groupe donne accès

D'accord, il faut être prudent ; mais comment vérifier précisément à quoi un groupe donne accès? La commande find vient à la rescousse dans ces moments difficiles.

sous root, exécuter une commande du genre

trouver les fichiers find

dans les répertoires / /usr /var

mais pas sur des montages -xdev

appartenant au groupe -group nom-du-groupe

lister le résultat -ls

%
  
# find / /usr /var -xdev -group <nom du groupe> -ls

Par exemple chez moi, j'ai le résultat suivant :

%
  
# find / -group dip -ls
 drwxr-s---   2 root  dip    1024 Jan 17  1999 /etc/ppp/peers
 -rw-r-----   1 root  dip     489 Jun 19  1998 /etc/ppp/peers/provider
 drwxr-s---   2 root  dip    1024 Jan 17  1999 /etc/chatscripts
 -rw-r-----   1 root  dip     200 Jun 19  1998 /etc/chatscripts/provider
 -rwsr-xr--   1 root  dip  105532 Jun 19  1998 /usr/sbin/pppd

Ce qui signifie que seul root et les membres du groupe dip peuvent :

lancer le programme pppd
accéder au fichiers dans /etc/chatscripts
accéder aux fichiers de /etc/ppp/peers (Mais en fait, c'est impossible, car /etc/ppp est protégé de telle sorte que seul root puisse y accéder, et pppd se prend pour root, donc tout va bien).

14.2.4 Accès à un CDROM

J'ai un lecteur de CD IDE qui s'appelle /dev/hdc. Après avoir installé Debian GNU/Linux, le périphérique /dev/hdc appartient au groupe disk (car il est impossible pour le programme d'installation de savoir si un périphérique IDE donné est un disque ou un lecteur de CD).

L'erreur serait d'ajouter les utilisateurs dans le groupe disk .

La bonne solution consiste à changer le périphérique /dev/hdc de groupe avec la commande :

%
  
  # chgrp cdrom /dev/hdc

S'il y a un lien symbolique cdrom vers /dev/hdc dans /dev, il est inutile de s'en préoccuper. Les permissions des liens sont ignorées, seules comptent les permissions de ce qu'ils désignent.

Ensuite, il suffit d'ajouter les utilisateurs au groupe cdrom .

14.2.5 Accès à un lecteur ZIP

J'ai un lecteur ZIP. Le fichier correspondant est /dev/sda, qui fait partie du groupe disk

La mauvaise méthode consiste à mettre les utilisateurs dans le groupe disk .

La bonne méthode consiste à créer un groupe qui ne servira qu'à ça. Par exemple un groupe nommé zip :

Ajouter un groupe zip

addgroup zip

Changer le groupe du lecteur sda

chgrp zip /dev/sda*

Enfin, ajouter les utilisateurs dans le groupe zip

Note On peut empêcher un utilisateur de partitionner une cartouche, tout en lui laissant la possibilité de formater des partitions existantes.

La plupart des cartouches sont vendues déjà partitionnées avec une seule grande partition (en général la quatrième) qui couvre l'intégralité de la cartouche.

En ne donnant l'accès qu'à cette quatrième partition (/dev/sda4) et non à la cartouche toute entière (/dev/sda), on laisse la possibilité à un utilisateur de formater une cartouche du commerce, mais pas de la repartitionner.

14.3 Changement dynamique de permission

Une question beaucoup moins banale sur le sujet est :

«Le système de groupe est très bien pour une machine personnelle, mais pas vraiment adaptée à une machine partagée et en réseau. En effet, on peut toujours utiliser les devices à distance si on peut se logger sur la machine. Sous solaris ou Red Hat, les droits des devices comme les lecteurs de disquettes et les cartes audio sont automatiquement positionnés en lecture/écriture pour la personne physiquement loggée sur la console et l'accès au device est bloqué pour le reste du monde. Comment faire de même sous Debian?»

Malheureusement, il n'y a pas de bonne solution pour faire cela sous Debian (pour l'instant). Deux pistes :

La méthode ``historique'' est d'utiliser le fichier /etc/login.defs , fait pour ça. Mais cette méthode est mauvaise car il est très facile de contourner le mécanisme pour conserver le droit même après s'être déloggé. La conclusion est dans les docs de PAM (la bibliothèque de sécurité, vérification de mots de passe et assimilés) : Il faut abandonner cette méthode.
La meilleur solution, qui consiste à transférer la propriété du périphérique à l'utilisateur qui est connecté sur le poste local, est celle choisie par Red Hat ou Solaris, mais elle n'est pas implémentée dans Debian. Certains membres de la liste ont dit continuer l'investigation pour adapter cette solution à Debian. Une piste : il faut utiliser PAM.