Le répertoire /etc/pam.d est utilisé pour configurer toutes
les applications PAM (il s'agissait de /etc/pam.conf dans les
anciennes versions ; le fichier pam.conf est toujours lu s'il
n'y a pas d'entrée /etc/pam.d/, son utilisation est
obsolète). Chaque application (chaque service, en réalité)
possède son propre fichier. Un fichier ressemble à ce qui suit :
84#84
La première ligne (commençant par le caractère #) est une ligne de
commentaire. Les trois lignes suivantes sont utilisées pour
l'autorisation de login. La deuxième s'assure, si l'utilisateur tente
de se connecter sous root, que le tty sous lequel il est connecté se
trouve dans le fichier/etc/securetty, s'il existe. La
troisième demande et vérifie le mot de passe. La quatrième vérifie
l'existence du fichier /etc/nologin, si ce fichier existe le
contenu est affiché et si l'utilisateur n'est pas root, la connexion
est refusée.
Notez que la vérification s'effectue sur les trois modules, même
si elle échoue au premier module. L'utilisateur qui se voit refuser
la connexion, n'en connaîtra donc pas (par mesure de sécurité) la
raison. Vous pouvez remplacer required par
requisite: si un module requisite échoue, les
modules suivants ne seront pas exécutés.
La cinquième ligne autorise l'accès au compte. Si vous avez par
exemple activé les shadow passwords, le module pam_pwdb.so
vérifie si le compte n'a pas expiré ou si le mot de passe a été changé
alors que la période allouée au changement est
déjà expirée.
La sixième ligne effectue une série de tests sur le mot de passe, pour
vérifier par exemple qu'il n'est pas décodable par un
programme de crack basé sur un dictionnaire.
Si le mot de passe utilisateur est modifié, la septième ligne indique
que c'est le module pam_pwdb.so qui doit être utilisé (il en
sera ainsi, sauf si le module auth a décidé que le mot de
passe doit être changé, ie. si un shadow password a expiré).
La huitième et dernière ligne indique que le module
pam_pwdb.so sera utilisé pour gérer la session.
Actuellement, ce module ne fait rien : vous pouvez le remplacer ou lui
ajouter d'autres modules.
Vous devez respecter l'ordre des lignes qui se trouvent à l'intérieur
d'un fichier. L'ordre dans lequel sont appelés les modules
required n'est pas très important, mais d'autres
drapeaux de contrôle sont disponibles. Alors que
optional est très rarement utilisé - et jamais par défaut
sur un système Red Hat Linux, l'ordre est par contre important pour
sufficient et requisite.
Jetons un coup d'7#7il à la configuration de auth pour
rlogin :
85#85
La configuration est presque similaire à celle de login, mais
un module supplémentaire est utilisé. Les modules sont aussi spécifiés
dans un ordre différent.
Premièrement, pam_securetty.so empêche les connexions root depuis les
terminaux non sécurisés. Les connexions root sont désactivées. Si vous voulez
les réactiver (dans ce cas, nous vous recommandons de ne pas être connecté à
Internet et d'utiliser un firewall de qualité), supprimez simplement
cette ligne.
Deuxièmement, pam_nologin.so vérifie /etc/nologin,
comme spécifié ci-dessus.
Troisièmement, si pam_rhosts_auth.so authentifie
l'utilisateur, il n'y aura pas de vérification de mot de passe. Si
pam_rhosts_auth.so n'authentifie pas l'utilisateur, l'échec
d'authentification est ignoré.
Enfin (si pam_rhosts_auth.so n'a pas réussi à authentifier
l'utilisateur), le module pam_pwdb.so lance
l'authentification normale (par mot de passe).
En cas d'échec, vous pouvez stopper l'authentification au niveau du module pam_securetty.so en remplaçant required par requisite.