Programmation avancée sous Linux

Chaque utilisateur sous Linux est identifié par un numéro unique appelé user ID, ou UID. Bien sûr, lorsque vous vous connectez, vous utilisez un nom d'utilisateur plutôt que cet UID. Le système effectue la conversion entre ce nom d'utilisateur et l'UID, et à partir de ce moment, seul l'user ID est pris en compte.

Vous pouvez en fait faire correspondre plus d'un nom d'utilisateur au même UID. En ce qui concerne le système, seuls les UID comptent. Il n'y a aucune façon de donner plus de droits à un utilisateur qu'à un autre s'ils ont tous deux le même UID.

Vous pouvez contrôler l'accès à un fichier ou à toute autre ressource en l'associant à un UID particulier. Dans ce cas, seul l'utilisateur disposant de cet UID peut accéder à la ressource. Par exemple, vous pouvez créer un fichier que vous serez le seul à pouvoir lire ou un répertoire où vous seul pourrez créer de nouveau fichier. Cela suffit dans la plupart des cas simples.

Parfois, cependant, vous avez besoin de partager une ressource entre plusieurs utilisateurs. Par exemple, si vous êtes un manager, vous pourriez vouloir créer un fichier que tous les managers pourraient lire mais pas les employés ordinaires. Linux ne vous permet pas d'associer plusieurs UID au même fichier, vous ne pouvez donc pas créer une liste de tous les gens auxquels vous souhaitez donner accès au fichier et les lier au fichier.

Par contre, vous pouvez créer un groupe. À chaque groupe est associé un numéro unique, appelé group ID ou GID. Chaque groupe contient un ou plusieurs user ID. Un même UID peut faire partie de plusieurs groupes mais un groupe ne peut pas contenir d'autres groupes; ils ne peuvent contenir que des utilisateurs. Comme les utilisateurs, les groupes ont des noms. Tout comme pour les noms d'utilisateurs, le nom d'un groupe n'a pas d'importance, le système utilise toujours le GID en interne.

Pour continuer avec notre exemple, vous pourriez créer un groupe managers et y placer les UID de tous les managers. Vous pourriez alors créer un fichier qui peut être lu par n'importe qui dans ce groupe mais pas par les gens qui y sont extérieurs. En général, vous ne pouvez associer qu'un seul groupe à une ressource. Il n'y a aucun moyen de spécifier que les utilisateurs peuvent accéder à un fichier s'ils font partie du groupe~7 ou du groupe~42, par exemple.

Si vous êtes curieux de connaître votre UID et les groupes auxquels vous appartenez, vous pouvez utiliser la commande id. Voici un exemple de la sortie de cette commande:

% id
uid=501(mitchell) gid=501(mitchell) groups=501(mitchell),503(csl)

la première partie indique que l'UID de l'utilisateur ayant invoqué la commande est~501. La commande détermine le nom d'utilisateur correspondant et l'affiche entre parenthèses. On voit ici que l'utilisateur 501 est dans deux groupes: le groupe~501 (appelé mitchell) et le groupe~503 (appelé csl). Vous vous demandez certainement pourquoi le groupe 501 apparaît deux fois: une première fois dans le champ gid et une seconde dans le champ groups. Nous y reviendrons plus tard.

10-1-1. Le superutilisateur▲

Jusqu'à maintenant, nous n'avons parlé que des commandes exécutées par un utilisateur en particulier. Cela ne colle pas exactement à la réalité car l'ordinateur ne sait jamais réellement quel utilisateur l'exécute. Si Ève découvre le nom d'utilisateur et le mot de passe d'Alice, Ève peut se connecter en tant qu'Alice et le système laisserait faire à Ève tout ce qu'Alice peut faire. Il ne connaît que l'UID en cours et non pas l'utilisateur qui saisit les commandes. Si on ne peut pas faire confiance à Alice pour garder secret son mot de passe, alors rien de ce que vous pourrez faire en tant que programmeur d'application ne pourra empêcher Ève d'accéder aux fichiers d'Alice. La responsabilité de la sécurité du système est partagée entre le développeur, les utilisateurs du système et les administrateurs du système.

À chaque processus est associé un UID et un GID. Lorsque vous invoquez une commande, elle lance un processus dont l'UID et le GID sont les vôtres. Lorsque nous disons qu'un utilisateur effectue une opération quelconque, nous voulons dire en réalité qu'un processus avec l'UID correspondant effectue cette opération. Lorsque le processus exécute un appel système, le noyau décide s'il y est autorisé. Pour cela, il examine les permissions associées aux ressources auxquelles le processus tente d'accéder et vérifie l'UID et le GID associés au processus tentant d'exécuter l'appel.

Désormais, vous savez ce que signifie le champ gid de la sortie de la commande id. Il indique le GID du processus courant. Même si l'utilisateur~501 fait partie de plusieurs groupes, le processus courant ne peut avoir qu'un seul GID. Dans l'exemple présenté précédemment, le GID en cours est~501.

Si vous devez manipuler des UID ou des GID dans votre programme (et vous aurez à le faire si vous écrivez des programmes concernant la sécurité), vous devez utiliser les types uid_t et gid_t définis dans l'en-tête <sys/types.h> ? même si les UID et GID ne sont en fait que des entiers, évitez de faire des suppositions sur le nombre de bits utilisé dans ces types ou d'effectuer des opérations arithmétiques en les utilisant. Traitez les comme un moyen obscur de manipuler les identifiants de groupe et d'utilisateur.

Pour récupérer l'UID et le GID du processus courant, vous pouvez utiliser les fonctions geteuid et getegid définies dans <unistd.h>. Ces fonctions ne prennent aucun paramètre et n'échouent jamais, il n'y a pas d'erreur à contrôler. Le Listing simpleid présente un simple programme qui fournit un sous-ensemble des fonctionnalités de la commande id:

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main()
{
  uid_t uid = geteuid ();
  gid_t gid = getegid ();
  printf ("uid=%d gid=%d\n", (int) uid, (int) gid);
  return 0;
}

Lorsque ce programme est exécuté (par le même utilisateur que celui qui a lancé le programme id dans l'exemple précédemment), la sortie est la suivante :

% ./simpleid
uid=501 gid=501

Un bon moyen de voir les utilisateurs et les groupes en actions est d'étudier les permissions du système de fichiers. En examinant la façon dont le système associe les permissions avec chaque fichier et en observant comment le noyau vérifie qui est autorisé à accéder à quels fichiers, le concept d'identifiant utilisateur et de groupe devrait devenir clair.

Chaque fichier a exactement un utilisateur propriétaire et un groupe propriétaire. Lorsque vous créez un nouveau fichier, il est détenu par l'utilisateur et le groupe du processus créateur(En fait, il existe de rares exceptions faisant intervenir les sticky bits, décrits plus loin dans la Section 10.3.2, « Sticky Bits ».).

Les opérations de base sur les fichiers, en ce qui concerne Linux, sont la lecture, l'écriture et l'exécution (Notez que la création et la suppression ne sont pas considérées comme des opérations sur le fichier, elles sont considérées comme des opérations sur le répertoire contenant le fichier. Nous en parlerons plus loin). Si vous ne pouvez

pas lire un fichier, Linux ne vous laissera pas en examiner le contenu. Si vous ne pouvez pas y écrire, vous ne pouvez pas modifier son contenu. Si vous ne disposez pas des droits d'exécution sur un fichier contenant le code d'un programme, vous ne pouvez pas exécuter ce programme.

Linux vous permet d'indiquer lesquelles de ces trois actions ? lire, écrire et exécuter ? peuvent être réalisées par l'utilisateur propriétaire, le groupe propriétaire et toute autre personne. Par exemple, vous pouvez dire que l'utilisateur propriétaire aura tous les droits, que les membres du groupe propriétaire pourront lire et exécuter le fichier (mais pas y écrire) et que personne d'autre n'y a accès.

Vous pouvez consulter ces bits de permission de façon interactive avec la commande ls en utilisant les options -l ou -o et par programmation via l'appel système stat. Vous pouvez définir de façon interactive les bits de permission avec le programme chmod(On fait parfois référence aux bits de permission en utilisant le terme mode. Le nom de la commande chmod est un diminutif pour « change mode ».) et par programmation avec l'appel système du même nom. Pour examiner les permissions d'un fichier appelé hello, utilisez ls -l hello. Voici un exemple de sortie:

% ls -l hello
-rwxr-x---    1 samuel csl 11734 Jan 22 16:29 hello

Les indications samuel et csl signifient que l'utilisateur propriétaire est samuel et que le groupe propriétaire est csl.

La chaîne de caractères a début de la ligne indique les permissions associées au fichier. Le premier tiret indique que le fichier est un fichier classique. Il serait remplacé par d pour un répertoire ou d'autres lettres dans le cas de fichiers spéciaux comme les périphériques (reportez-vous au Chapitre peripheriques, « Périphériques ») ou les canaux nommés (voyez le Chapitre IPC, « Communication Interprocessus », Section tubes, « Tubes »). Les trois caractères suivants représentent les permissions de l'utilisateur propriétaire: ils indiquent que samuel peut lire, écrire et exécuter le fichier. Les trois caractères d'après donnent les permissions des membres du groupe csl; ses membres ne peuvent que lire et exécuter le fichier. Enfin, les trois derniers caractères indiquent les permissions de toute autre personne; ici, tout utilisateur n'étant pas samuel et ne faisant pas partie du groupe csl ne peut rien faire avec le fichier hello.

Voyons comment cela fonctionne. Tout d'abord, essayons d'accéder au fichier en tant qu'utilisateur nobody, qui ne fait pas partie du groupe csl:

% id
uid=99(nobody) gid=99(nobody) groups=99(nobody)
% cat hello
cat: hello: Permission denied
% echo hi > hello
sh: ./hello: Permission denied
% ./hello
sh: ./hello: Permission denied

Nous n'avons pas le droit de lire le fichier, c'est pourquoi cat échoue; nous ne pouvons pas écrire dans le fichier, c'est pourquoi echo échoue; et nous n'avons pas le droit d'exécuterle fichier, c'est pourquoi ./hello échoue.

Les choses s'arrangent si nous accédons au fichier en tant que mitchell, qui n'est pas membre du groupe csl:

% id
uid=501(mitchell) gid=501(mitchell) groups=501(mitchell),503(csl)
% cat hello
#!/bin/bash
echo "Hello, world."
% ./hello
Hello, world.
% echo hi > hello
bash: ./hello: Permission denied

Nous pouvons afficher le contenu du fichier et nous pouvons l'exécuter (il s'agit d'un simple script shell) mais nous ne pouvons toujours pas y écrire.

Si nous sommes identifiés en tant que propriétaire (samuel), nous pouvons même écraser le fichier:

% id
uid=502(samuel) gid=502(samuel) groups=502(samuel),503(csl)
% echo hi > hello
% cat hello
hi

Vous pouvez modifier les permissions associées avec un fichier si vous êtes son propriétaire (ou le superutilisateur). Par exemple, si vous voulez désormais permettre à tout le monde d'exécuter le fichier, vous pouvez faire ce qui suit:

% chmod o+x hello
% ls -l hello
-rwxr-x--x    1 samuel csl 3 Jan 22 16:38 hello

Notez qu'il y a maintenant un x à la fin de la première chaîne de caractères. L'option o+x signifie que vous voulez donner la permission d'exécution à tous les autres gens (ni le propriétaire, ni les membres du groupe propriétaire). Pour révoquer les permissions en écriture du groupe, vous utiliseriez g-w. Consultez la page de manuel de la section~1 sur chmod pour plus de détails sur sa syntaxe:

% man 1 chmod

Dans un programme, vous pouvez utiliser l'appel système stat pour déterminer les permissions associées à un fichier. Cette fonction prend deux paramètres: le nom du fichier sur lequel vous voulez des renseignements et l'adresse d'une structure de données renseignée avec des informations sur le fichier. Consultez l'Appendice B, « E/S de Bas Niveau », Section B.2, « stat », pour une présentation des autres informations que vous pouvez obtenir via stat. Le Listing statperm montre un exemple d'utilisation de stat pour déterminer les permissions associées à un fichier.

#include <stdio.h>
#include <sys/stat.h>

int main (int argc, char* argv[])
{
  const char* const filename = argv[1];
  struct stat buf;

  /* Récupère les informations sur le fichier. */
  stat (filename, &amp;buf);
  /* Affiche un message si les permissions sont définies de façons 
     à ce que le propriétaire puisse y écrire. */
  if (buf.st_mode &amp; S_IWUSR)
    printf ("Le propriétaire peut écrire dans '%s'.\n", filename);
  return 0;
}

Si vous exécutez ce programme sur notre script hello, il indique:

% ./stat-perm hello
Le propriétaire peut écrire dans 'hello'.

La constante S_IWUSR correspond à la permission en écriture pour le propriétaire. Il y a une constante pour chaque bit. Par exemple, S_IRGRP correspond à la permission en lecture pour le groupe propriétaire et S_IXOTH à la permission en exécution pour les utilisateurs qui ne sont ni propriétaires, ni membre du groupe. Si vous stockez les permissions dans une variable, utilisez le typedef mode_t. Comme la plupart des appels système, stat renverra~-1 et positionnera errno s'il ne peut pas obtenir les informations sur le fichier.

Vous pouvez utiliser la fonction chmod pour modifier les bits de permission d'un fichier existant. Appelez chmod avec le nom du fichier dont vous voulez changer les permission et les bits à activer sous forme d'un OU binaire entre les différentes constantes citées précédemment. Par exemple, l'extrait suivant rend hello lisible et exécutable par le propriétaire mais désactive toutes les autres permissions associées à hello:

chmod ("hello", S_IRUSR | S_IXUSR);

Le même système de bits de permission s'applique aux répertoires mais ces bits ont des significations différentes. Si un utilisateur est autorisé à lire le répertoire, alors il peut consulter la liste des fichiers présents dans ce répertoire. Avec les droits en écriture, il est possible d'ajouter ou de supprimer des fichiers. Notez qu'un utilisateur peut supprimer des fichiers d'un répertoire s'il a les droits en écriture sur celui-ci, même s'il n'a pas la permission de modifier le fichier qu'il supprime. Si un utilisateur a les droits d'exécution sur un répertoire, il a le droit d'y entrer et d'accéder aux fichiers qu'il contient. Sans droit d'exécution sur un répertoire, un utilisateur ne peut pas accéder aux fichiers qu'il contient, indépendamment des droits qu'il détient sur les fichiers eux-mêmes.

Pour conclure, observons comment le noyau décide d'autoriser ou non un processus à accéder à un fichier donné. Tout d'abord, il détermine si l'utilisateur demandant l'accès est le propriétaire du fichier, un membre du groupe propriétaire ou quelqu'un d'autre. La catégorie dans laquelle tombe l'utilisateur est utilisée pour déterminer quel ensemble de bits lecture/écriture/exécution est vérifié. Puis, le noyau contrôle l'opération effectuée par rapport aux permissions accordées à l'utilisateur(Le noyau peut également refuser l'accès à un fichier si un répertoire dans le chemin du fichier est inaccessible. Par exemple, si un processus n'a pas le droit d'accéder au répertoire /tmp/private, il ne pourra pas lire /tmp/private/data, même si les permissions de ce dernier sont définies de façon à l'y autoriser.).

Il y a une exception qu'il convient de signaler: les processus s'exécutant en tant que root (avec l'user ID~0) sont toujours autorisés à accéder à n'importe quel fichier, quelques soient les permissions qui y sont associées.

10-3-1. Faille de sécurité: les Programmes non Exécutables▲

10-3-2. Sticky Bits▲

% ls -ld /tmp
drwxrwxrwt   12 root root 2048 Jan 24 17:51 /tmp

% chmod o+t répertoire

chmod (dir_path, S_IRWXU | S_IRWXG | S_IRWXO | S_ISVTX);

Jusqu'à maintenant, nous avons parlé de l'UID et du GID associés avec un processus comme s'il n'y en avait qu'un seul de chaque. Mais, en réalité, ce n'est pas aussi simple.

Chaque processus a en réalité deux user ID: l'user ID effectif et l'user ID réel (bien sûr, il y a également un group ID effectif et un group ID réel; presque tout ce qui est vrai pour les user ID l'est également pour les group ID). La plupart du temps, le noyau ne se préoccupe que du user ID effectif. Par exemple, si un processus tente d'ouvrir un fichier, le noyau vérifie l'user ID effectif pour décider s'il laisse le processus accéder au fichier.

Les fonctions geteuid et getegid décrites précédemment renvoient l'user ID et le group ID effectifs. Les fonctions analogues getuid et getgid renvoient l'user ID et le group ID réels.

Si le noyau ne s'occupe que de l'user ID effectif, il ne semble pas très utile de faire la distinction entre user ID réel et effectif. Cependant, il y a un cas très important dans lequel le user ID réel est pris en compte. Si vous voulez changer l'user ID effectif d'un processus en cours d'exécution, le noyau vérifie l'user ID réel et l'user ID effectif.

Avant d'observer comment vous pouvez changer l'user ID effectif d'un processus, examinons pourquoi vous pourriez vouloir le faire en reprenant l'exemple de notre application de comptabilité. Supposons qu'il y ait un processus serveur qui ait besoin de consulter tout fichier présent sur le système, peu importe qui l'ait créé. Un tel processus doit s'exécuter en tant que root car lui seul est sûr de pouvoir accéder à n'importe que fichier. Mais supposons maintenant qu'une requête arrive de la part d'un utilisateur particulier (disons mitchell) pour accéder à des fichiers quelconques. Le processus serveur pourrait examiner avec attention les permissions associées avec les fichiers concernés et essayer de déterminer si mitchell devrait être autorisé à accéder à ces fichiers. Mais cela signifierait dupliquer tous les traitements que le noyau ferait de toutes façons. Réimplémenter cette logique serait complexe, sujet à des erreurs et pénible.

Une meilleure approche est simplement de modifier temporairement l'user ID effectif du processus pour ne plus qu'il soit celui de root mais celui de mitchell puis d'essayer d'effectuer les opérations demandées. Si mitchell n'a pas le droit d'accéder aux données, le noyau interdira l'accès au processus et renverra des informations adéquates sur l'erreur. Une fois que les opérations demandées par mitchell sont terminées, le processus peut récupérer son user ID effectif original qui est root.

Les programmes qui authentifient les utilisateurs lorsqu'ils essaient de se connecter tirent eux aussi avantage de cette possibilité de modifier les user ID. Ces programmes s'exécutent en tant que root ? lorsque l'utilisateur saisit un login et un mot de passe, le programme de connexion vérifie le nom d'utilisateur et le mot de passe dans la base de données du système. Puis il change à la fois ses user ID réel et effectif afin de devenir cet utilisateur. Enfin, le programme de connexion appelle exec pour lancer le shell de l'utilisateur, ce qui permet à l'utilisateur d'avoir un environnement dans lequel les user ID réel et effectif sont les siens.

La fonction utilisée pour modifier les user ID d'une processus est setreuid (il y a, bien sûr, une fonction setregid similaire). Cette fonction prend deux arguments. Le premier argument est l'user ID réel désiré; le second est l'user ID effectif demandé. Par exemple, voici comment vous échangeriez les user ID réel et effectif:

setreuid (geteuid(), getuid ());

Bien sûr, le noyau ne laisse pas n'importe quel processus changer son user ID. Si un processus pouvait modifier son user ID effectif à volonté, alors, toute personne pourrait facilement prendre l'identité de n'importe quel autre utilisateur simplement en changeant l'user ID effectif de l'un de ses processus. Le système laissera un processus disposant d'un user ID effectif de 0 modifier son user ID à sa guise (encore une fois, remarquez la puissance dont dispose un processus s'exécutant en tant que root! Un processus dont l'user ID effectif est 0 peut faire tout ce qu'il lui plaît). Tout autre processus, par contre, ne peut faire que l'une des actions suivantes:

• définir son user ID effectif pour qu'il soit le même que son user ID réel ;
• définir son user ID réel pour qu'il soit le même que son user ID effectif ;
• échanger les deux identifiants.

La première possibilité serait utilisée par notre système de comptabilité lorsqu'il a terminé d'accéder au fichiers en tant que mitchell et veut redevenir root. La seconde par un programme de connexion une fois qu'il a défini l'user ID effectif pour qu'il soit celui de l'utilisateur qui s'est connecté. Définir l'user ID réel permet de s'assurer que l'utilisateur ne pourra jamais redevenir root. L'échange des deux identifiants est avant tout une fonctionnalité historique, les programmes modernes l'utilisent rarement.

Vous pouvez passer~-1 à la place de l'un des deux arguments de setreuid si vous ne voulez pas modifier l'user ID correspondant. Il existe également une fonction raccourci appelée seteuid. Cette fonction définit l'user ID effectif mais ne modifie pas l'user ID réel. Les deux instructions suivantes font toutes deux la même chose:

seteuid (id);
setreuid (-1, id);

10-4-1. Programmes Setuid▲

% whoami
mitchell
% su
Password: ...
% whoami
root

#include <stdio.h>
#include <unistd.h>

int main ()
{
  printf ("uid=%d euid=%d\n", (int) getuid (), (int) geteuid ());
  return 0;
}

-rwsrws--x 1 root root 11931 Jan 24 18:25 setuid-test

% whoami
mitchell
% ./setuid-test
uid=501 euid=0

% ls -l program
-rwxr-xr-x    1 samuel csl 0 Jan 30 23:38 program
% chmod g+s program
% ls -l program
-rwxr-sr-x    1 samuel csl 0 Jan 30 23:38 program
% chmod u+s program
% ls -l program
-rwsr-sr-x    1 samuel csl 0 Jan 30 23:38 program

% ls -l /bin/su
-rwsr-xr-x    1 root root 14188 Mar 7 2000 /bin/su

Souvent, lorsque vous créez un programme setuid, vous souhaitez n'en autoriser l'accès qu'à certains utilisateurs. Par exemple, le programme su ne vous laisse devenir root que si vous disposez du mot de passe correspondant. Le programme vous oblige à prouver que vous pouvez devenir root avant de vous permettre de faire quoi que ce soit. Ce mécanisme est appelé authentification ? le programme su vérifie que vous êtes celui que vous prétendez être.

Si vous administrez un système très sécurisé, l'authentification des utilisateurs par le biais d'un simple mot de passe ne vous satisfera probablement pas. Les utilisateurs ont tendence à noter leur mot de passe et les personnes mal intentionnées à les découvrir. Les utilisateurs choisissent généralement des mots de passe comme leur date de naissance, le nom de leur animal de compagnie, etc(On a découvert que les administrateurs système avaient tendance à choisir le mot dieu pour mot de passe plutôt que n'importe quel autre (pensez-en ce que vous voulez). Aussi, si vous avez besoin d'un accès root sur une machine et que l'administrateur n'est pas là, une inspiration divine pourra peut être vous aider.). Les mot de passe ne sont finalement pas une bonne garantie de sécurité.

Par exemple, beaucoup d'organisations utilisent désormais un système de mots de passe à « usage unique » générés par des cartes d'identité électronique que les utilisateurs gardent sur eux. Le même mot de passe ne peut être utilisé deux fois et vous ne pouvez obtenir de mot de passe valide à partir de la carte qu'en entrant un code d'identification. L'attaquant doit donc obtenir la carte et le code pour accéder au système. Dans des complexes extrêmement sécurisés, les scan rétiniens et d'autres types de systèmes d'identification biométriques sont utilisés.

Si vous écrivez un programme qui doit authentifier ses utilisateurs, vous devriez permettre à l'administrateur système de sélectionner le moyen d'authentification qu'il souhaite utiliser. GNU/Linux propose une bibliothèque très utile pour vous faciliter la tâche. Ce mécanisme, appelé Pluggable Authentication Modules (Modules d'Authentification Enfichable), ou PAM, facilite l'écriture d'application qui authentifient leurs utilisateurs comme le désire l'administrateur système.

Il est plus simple de comprendre le fonctionnement de PAM en étudiant une application PAM simple. Le Listing pam illustre l'utilisation de PAM.

#include <security/pam_appl.h>
#include <security/pam_misc.h>
#include <stdio.h>

int main ()
{
  pam_handle_t* pamh;
  struct pam_conv pamc;

  /* Initialise la conversation PAM. */
  pamc.conv = &amp;misc_conv;
  pamc.appdata_ptr = NULL;
  /* Démarre une nouvelle session d'authentification. */
  pam_start ("su", getenv ("USER"), &amp;pamc, &amp;pamh);
  /* Authentifie l'utilisateur. */
  if (pam_authenticate (pamh, 0) != PAM_SUCCESS)
    fprintf (stderr, "Échec de l'authentification !\n");
  else
    fprintf (stderr, "Authentification OK.\n");
  /* Fini. */
  pam_end (pamh, 0);
  return 0;
}

Pour compiler ce programme, vous devez le lier à deux bibliothèques: libpam et une bibliothèque utilitaire appelée libpam_misc:

% gcc -o pam pam.c -lpam -lpam_misc

Ce programme commence par construire un objet de conversation PAM. Cet objet est utilisé par la bibliothèque PAM lorsqu'elle a besoin d'obtenir des informations de la part des utilisateurs. La fonction misc_conv utilisée dans cet exemple est une fonction standard utilisant le terminal pour les entrées sorties. Vous pouvez écrire votre propre fonction qui affiche une boîte de dialogue, utilise la parole pour les entrées/sorties ou propose même des méthodes d'interactions plus exotiques. Le programme appelle ensuite pam_start. Cette fonction initialise la bibliothèque PAM. Le premier argument est un nom de service. Vous devez utiliser un nom qui identifie de façon unique votre application. Par exemple, si votre application s'appelle whizbang, vous devriez utiliser ce nom pour le service. Cependant, le programme ne fonctionnera probablement pas à moins qu'un administrateur système ne configure explicitement le système pour fonctionner avec votre service. Revenons à notre exemple, nous utilisons le service su, qui indique que notre programme authentifie les utilisateurs de la même façon que la commande su. Vous ne devriez pas utiliser cette technique dans un programme réel. Sélectionnez un nom de service qui vous est propre et concevez vos scripts d'installation pour aider l'administrateur à configurer PAM correctement pour votre application.

Le second argument est le nom de l'utilisateur que vous voulez authentifier. Dans cet exemple, nous utilisons la valeur de la variable d'environnement USER (en théorie, il s'agit du nom d'utilisateur correspondant à l'user ID effectif du processus courant, mais ce n'est pas toujours le cas). Dans la plupart des programmes réels, vous afficheriez une invite pour saisir le nom d'utilisateur. Le troisième argument est la conversation PAM, que nous avons présentée précédemment. L'appel à pam_start renseigne le handle passé en quatrième argument. Passez ce handle aux appels ultérieurs aux fonctions de la bibliothèque PAM.

Ensuite, le programme appelle pam_authenticate. Le second argument vous permet de spécifier diverses options; la valeur 0 demande l'utilisation des valeurs par défaut. La valeur de retour de cette fonction indique le résultat de l'authentification.

Finalement, le programme appelle pam_end pour libérer toutes les structures de données allouées.

Supposons que le mot de passe pour l'utilisateur courant soit « password » (un mot de passe extrêmement faible). Alors, l'exécution de ce programme avec le mot de passe correct produit le comportement attendu:

% ./pam
Password: password
Authentification OK.

Si vous exécutez ce programme dans un terminal, le mot de passe n'apparaîtra probablement pas lorsque vous le saisirez: il est masqué pour éviter qu'une autre personne ne puisse l'apercevoir alors que vous l'entrez.

Par contre, si un hacker tente d'utiliser un mauvais mot de passe, la bibliothèque PAM signalera l'échec correctement:

% ./pam
Password: raté
Échec de l'authentification !

Les bases que nous avons présenté sont suffisantes pour la plupart des programmes simples. Une documentation complète sur le fonctionnement de PAM est disponible sous /usr/doc/pam sur la plupart des systèmes GNU/Linux.

Bien que ce chapitre présente quelques failles de sécurité répandues, vous ne devez en aucun cas compter sur ce livre pour couvrir toutes les failles possibles. Beaucoup on déjà été trouvés et beaucoup plus attendent de l'être. Si vous essayez d'écrire du code sécurisé, il n'y a réellement pas d'autre solution que de faire appel à un expert pour un audit de code.

10-6-1. Dépassement de tampon▲

#include <stdio.h>

int main ()
{
  /* Personne de censé n'aurait plus de 32 caractères dans son nom
     d'utilisateur. De plus, il me semble qu'UNIX ne permet que des
     nom de 8 caractères. Il y a donc suffisamment de place. */
  char username[32];
  /* Demande le nom de l'utilisateur. */
  printf ("Saisisez votre identifiant de connexion : ");
  /* Lit une ligne saisie par l'utilisateur. */
  gets (username);
  /* Traitements divers... */

  return 0;
}

string username;
getline (cin, username);

#include <fcntl.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>

/* Renvoie le descripteur de fichier d'un nouveau fichier temporaire.
   Le fichier pourra être lu ou écrit par l'user ID effectif du processus
   courant et par personne d'autre.

   Renvoie -1 si le fichier temporaire ne peut pas être créé.  */

int secure_temp_file ()
{
  /* Ce descripteur de fichier pointe vers /dev/random et nous permet
     de disposer d'une bonne source de nombres aléatoires. */
  static int random_fd = -1;
  /* Entier aléatoire. */
  unsigned int random;
  /* Tampon utilisé pour convertir random en chaîne de caractères.
     Le tampon à une taille fixe, ce qui signifie que nous sommes
     potentiellement vulnérables à un bug de dépassement de tampon si
     les entiers de la machine d'exécution tiennent sur un nombre
     *conséquent* de bits. */
  char filename[128];
  /* Descripteur de fichier du nouveau fichier temporaire. */
  int fd;
  /* Informations sur le nouveau fichier. */
  struct stat stat_buf;

  /* Si nous n'avons pas encore ouvert /dev/random nous le faisons
     maintenant. Cette façon de faire n'est pas threadsafe. */
  if (random_fd == -1) {
  /* Ouvre /dev/random. Notez que nous supposons ici que /dev/random est
     effectivement une source de bits aléatoire et non pas un fichier
     rempli de zéros placé ici par l'attaquant. */
  random_fd = open ("/dev/random", O_RDONLY);
  /* Abandonne si l'on ne peut pas ouvrir /dev/random. */
  if (random_fd == -1)
    return -1;
  }

  /* Lit un entier à partir de /dev/random. */
  if (read (random_fd, &amp;random, sizeof (random)) !=
      sizeof (random))
    return -1;
  /* Crée un fichier à partir du nombre aléatoire. */
  sprintf (filename, "/tmp/%u", random);

  /* Tente d'ouvrir le fichier. */
  fd = open (filename,
             /* Nous utilisons O_EXECL, 
                même si cela ne fonctionne pas avec NFS. */
             O_RDWR | O_CREAT | O_EXCL,
             /* Personne ne doit pouvoir lire ou écrire dans le fichier. */
             S_IRUSR | S_IWUSR);
  if (fd == -1)
    return -1;
  /* Appelle lstat sur le fichier afin de s'assurer qu'il
     ne s'agit pas d'un lien symbolique. */
  if (lstat (filename, &amp;stat_buf) == -1)
    return -1;
  /* Si le fichier n'est pas un fichier traditionnel, quelqu'un
     a tenté de nous piéger. */
  if (!S_ISREG (stat_buf.st_mode))
    return -1;
  /* Si le fichier ne nous appartient pas, quelqu'un d'autre pourrait
     le supprimer, le lire ou le modifier alors que nous nous en
     servons. */
  if (stat_buf.st_uid != geteuid () || stat_buf.st_gid != getegid ())
    return -1;
  /* Si il y a d'autres bits de permissions actifs,
     quelque chose cloche. */
  if ((stat_buf.st_mode &amp; ~(S_IRUSR | S_IWUSR)) != 0)
    return -1;

  return fd;
}

% grep -x word /usr/dict/words

#include <stdio.h>
#include <stdlib.h>

/* Renvoie une valeur différente de 0 si et seulement si WORD
   figure dans /usr/dict/words. */

int grep_for_word (const char* word)
{
  size_t length;
  char* buffer;
  int exit_code;

/* Construit la chaîne "grep -x WORD /usr/dict/words". Alloue la chaîne 
   dynamiquement pour éviter les dépassements de tampon. */
  length =
    strlen ("grep -x ") + strlen (word) + strlen (" /usr/dict/words") + 1;
  buffer = (char*) malloc (length);
  sprintf (buffer, "grep -x %s /usr/dict/words", word);

  /* Exécute la commande. */
  exit_code = system (buffer);
  /* Libère le tampon. */
  free (buffer);
  /* Si grep a renvoyé 0, le mot était présent dans le dictionnaire. */
  return exit_code == 0;
}

foo /dev/null; rm -rf /

grep -x foo /dev/null; rm -rf / /usr/dict/words