Authentification de l'utilisateur avec PAM

Modules PAM

Quatre types de modules sont définis par le standard PAM.

• Les modules auth assurent l'authentification réelle en demandant et en vérifiant un mot de passe, et ils définissent des "certificats d'identité" tels que l'appartenance à un groupe ou des "tickets" kerberos.

• Les modules account vérifient si l'authentification est permise (si le compte n'a pas expiré, si l'utilisateur est autorisé à se connecter à cette heure du jour, etc.).

• Les modules password sont utilisés pour définir des mots de passe.

• Les modules session sont utilisés une fois qu'un utilisateur a été authentifié pour lui permettre d'utiliser son compte, peut-être en montant le répertoire personnel de l'utilisateur ou en rendant sa boîte aux lettres disponible.

Ces modules peuvent être empilés, en sorte d'en utiliser plusieurs. Par exemple, rlogin utilise normalement au moins deux méthodes d'authentification : si l'authentification rhosts aboutit, il suffit de permettre la connexion ; si elle échoue, une authentification par mot de passe standard intervient.

Il est possible d'ajouter de nouveaux modules à tout instant et de créer des applications compatibles PAM pour les utiliser. Par exemple, si vous avez un système de calculatrice à mot de passe unique et écrivez un module pour le prendre en charge (une documentation sur l'écriture de modules est fournie avec le système et figure dans le répertoire /usr/share/doc/pam*), les programmes compatibles PAM peuvent utiliser le nouveau module et travailler avec la nouvelle calculatrice à mot de passe unique sans recompilation ou autre modification.

Services

Chaque programme utilisant des PAM définit son propre nom de "service". Le programme login définit le type de service login, ftpd définit le type de service ftp, etc. En général, le type de service est le nom du programme utilisé pour accéder au service, pas celui du programme (s'il y a une différence) utilisé pour fournir le service.

fichiers de configuration

Le répertoire /etc/pam.d est utilisé pour configurer toutes les applications PAM (il s'agissait du répertoire /etc/pam.conf dans les précédentes les versions de PAM ; lorsque le fichier pam.conf est en cours de lecture, si aucune entrée /etc/pam.d/ n'est trouvée, son utilisation est refusée). Chaque application (en réalité, chaque service) a son propre fichier. Voici à quoi ressemble un fichier :

#%PAM-1.0
auth      required  /lib/security/pam_securetty.so
auth      required  /lib/security/pam_unix.so shadow nullok
auth      required  /lib/security/pam_nologin.so
account   required  /lib/security/pam_unix.so
password  required  /lib/security/pam_cracklib.so
password  required  /lib/security/pam_unix.so shadow nullok use_authtok
session   required  /lib/security/pam_unix.so
        

La première ligne est un commentaire (toute ligne commençant par le signe # est un commentaire). Les lignes deux à quatre empilent trois modules à utiliser pour l'autorisation de connexion. La ligne deux s'assure que si l'utilisateur essaie de se connecter comme root, le télétype sur lequel il se connecte figure dans le fichier /etc/securetty si ce dernier existe. La ligne trois fait en sorte que l'utilisateur soit invité à entrer un mot de passe et que ce mot de passe soit contrôlé. La ligne quatre vérifie si le fichier /etc/nologin existe et, dans l'affirmative, affiche le contenu du fichier ; si l'utilisateur n'est pas connecté en tant que root, elle ne le laisse pas se connecter.

Les trois modules sont contrôlés, même si le premier échoue. Il s'agit d'une décision de sécurité — elle a pour but d'empêcher l'utilisateur de savoir pourquoi son authentification a été refusée car, s'il le savait, il lui serait plus facile de pirater la procédure d'authentification. Vous pouvez modifier ce comportement en remplaçant required par requisite. Si un module requisite retourne une erreur, PAM échoue immédiatement, sans appeler d'autres modules.

La cinquième ligne entraîne l'exécution de toute comptabilisation nécessaire. Par exemple, si les mots de passe masqués ont été activés, le module pam_unix.so vérifie si le compte a expiré, si l'utilisateur n'a pas changé son mot de passe et si la période pendant laquelle il lui est permis de changer le mot de passe est arrivée à expiration.

La sixième ligne soumet le nouveau mot de passe à une série de tests pour s'assurer qu'il ne puisse pas, par exemple, être aisément deviné à l'aide d'un programme de décryptage de mot de passe basé sur une dictionnaire.

La septième ligne (qui peut être entrée sur plusieurs lignes) spécifie que, si le programme login modifie le mot de passe de l'utilisateur, il doit utiliser le module pam_unix.so pour le faire (il le fait uniquement si un module auth a déterminé que le mot de passe doit être modifié — par exemple, si un mot de passe masqué a expiré).

La huitième et dernière ligne spécifie que le module pam_unix.so doit être utilisé pour gérer la session. Actuellement, ce module ne fait rien ; il pourrait être remplacé (ou complété par empilage) par tout module nécessaire.

Il faut noter que l'ordre des lignes à l'intérieur de chaque fichier a de l'importance. Bien que l'ordre dans lequel les modules requis sont appelés n'ait pas grande importance, d'autres indicateurs de contrôle sont disponibles. Si optional est rarement utilisé et jamais utilisé par défaut sur un système Red Hat Linux, sufficient et requisite font que l'ordre devient important.

Examinons la configuration de auth pour rlogin :

auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_nologin.so
        

Premièrement, si pam_rhosts_auth.so authentifie l'utilisateur, PAM retourne immédiatement l'avis de succès à rlogin sans vérifier le mot de passe. Si pam_rhosts_auth.so ne parvient pas à authentifier l'utilisateur, l'échec de l'authentification est ignoré.

Deuxièmement, pam_securetty.so interdit les connexions root sur des terminaux non sécurisés. Ceci interdit efficacement toutes les tentatives rlogin de connexion en tant que root. Si vous voulez les permettre (auquel cas nous conseillons de ne pas être connecté à Internet ou d'être protégé par un bon pare-feu), vous pouvez simplement supprimer cette ligne.

Troisièmement, si pam_rhosts_auth.so n'est pas parvenu à authentifier l'utilisateur, le module pam_stack.so effectue une authentification par mot de passe normale.

Enfin, pam_nologin.so vérifie /etc/nologin, comme spécifié ci-dessus.

Notez que, si vous ne voulez pas demander un mot de passe et que la vérification securetty échoue, vous pouvez changer le module pam_securetty.so de required en requisite.

Mots de passe masqués

Le module pam_unix.so détecte automatiquement si vous utilisez un mot de passe masqué et effectue tous les ajustements nécessaires. Consultez la la section intitulée Utilitaires masqués pour plus de détails.

Rexec et PAM

Pour des raisons de sécurité, rexec n'est pas activé dans Red Hat Linux 7.0. Pour l'activer, commentez une ligne du fichier /etc/pam.d/rexec. Voici un exemple de fichier (votre fichier peut être légèrement différent) :

#%PAM-1.0
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_stack.so service=system-auth
        

Pour activer rexec, la ligne faisant référence au module pam_nologin.so doit être identifiée comme un commentaire :

#%PAM-1.0
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_stack.so service=system-auth
#auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_stack.so service=system-auth
        

Une fois ce fichier modifié, rexec est activé.

	Remarque
	Si votre fichier /etc/pam.d/rexec contient une ligne faisant référence au module pam_securetty.so, vous ne serez pas en mesure d'exécuter la commande rexec en tant que root. Pour ce faire, vous devez également commenter la ligne faisant référence au module pam_securetty.so.

Remarque

La plupart des fichiers de configuration doivent être réécrits afin de simplifier les modifications à l'échelle du système, de sorte que, lorsqu'une configuration doit être modifiée, elle ne doive l'être qu'à un seul endroit. Cette modification intervient en raison du fichier pam_stack qui vous permet d'appeler, à partir de la pile d'un service particulier, la pile définie pour n'importe quel autre service. Reportez-vous à la page man de pam_stack pour plus d'informations.