Dans un article précédent, j'ai décrit le flux d'une application appelant les bibliothèques PAM pour l'authentification à un niveau très élevé. Dans cet article, nous allons parcourir les fichiers de configuration pour un sudo local commande.
Lors de l'utilisation de sudo , nous changeons d'utilisateur et faisons quelque chose. Ce changement de privilège nécessite la vérification que nous sommes bien qui nous disons être et que nous sommes autorisés à effectuer l'action donnée. Les /etc/sudoers Le fichier contrôle qui peut faire quoi, mais le processus appelle toujours PAM pour toute vérification d'authentification. Dans le cadre de ces appels, le processus s'identifie, puis libpam recherche un fichier de configuration correspondant dans /etc/pam.d répertoire.
$ cat /etc/pam.d/sudo
#%PAM-1.0
#Type ReturnCode Modules Options
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Comme beaucoup d'autres répertoires *.d, la gestion des packages peut ajouter ou supprimer un fichier de ce répertoire. Le sudo RPM ajoute le /etc/pam.d/sudo fichier.
$ rpm -qf /etc/pam.d/sudo
sudo-1.9.0-0.1.b4.fc31.x86_64
Une version amont peut avoir une variété d'entrées, mais ce package fourni par la distribution inclut un fichier de configuration qui a plusieurs include déclarations au commun /etc/pam.d/system-auth fichier qui est fourni par le pam paquet.
Champs du fichier de configuration
Le premier champ de ce fichier identifie un Type d'appel fait à PAM. Les lignes de même type sont regroupées. Il existe quatre types :auth, compte, mot de passe et session. Regardez man pam pour une description de chaque type.
Le deuxième champ est connu sous le nom de ReturnCode . Ce champ permet à PAM de savoir comment gérer les résultats du test du module. Les codes de retour indiquent si un test est obligatoire ou facultatif. Les codes peuvent également être utilisés pour indiquer que la ligne n'est pas un test de module avec des options mais plutôt le nom d'un autre fichier de configuration avec des vérifications supplémentaires. Une description complète des codes de retour se trouve dans man pam.conf , et les plus courants sont abordés plus loin dans cet article.
Le reste de la ligne contient le nom du module et les options de ce module. Le nom du module doit correspondre à un module disponible dans le /etc/lib64/security annuaire. Les options peuvent être différentes selon le type d'appel effectué. Certains modules n'effectuent des tests que pour certains types d'appels. Utilisez la page de manuel de chaque module pour voir des exemples et en savoir plus sur les utilisations et les options disponibles.
L'ordre des entrées dans un type d'appel est important. Cela est principalement dû à la façon dont les codes de retour sont traités, mais dans certains cas à cause d'une action de module. Quand libpam reçoit un message "done" ou "die", il rapporte le résultat global au processus appelant.
La configuration pour sudo a plusieurs inclure lignes. Ces lignes indiquent libpam pour inclure toutes les lignes d'un type donné du fichier de configuration spécifié. Il existe également une sous-pile option, qui est similaire dans la façon dont il inclut les lignes d'un fichier de configuration donné, mais sur un "done" ou "die", il renvoie à la sous-pile instruction au lieu du processus d'origine appelant libpam . Les anciennes versions de PAM avaient d'autres variations sur la façon dont les autres fichiers de configuration étaient inclus. Par exemple, lorsque j'ai commencé à explorer PAM il y a près de 20 ans, il y avait un module spécifique appelé avec les fichiers de configuration comme argument. Le mot clé "include" n'était pas valide pour le ReturnCode champ.
Codes de retour dans les fichiers de configuration centraux
Le /etc/pam.d/sudo le fichier présenté précédemment est assez court. Trois des quatre types d'appel n'ont qu'un include d'un autre dossier. Le /etc/pam.d/system-auth est plus typique d'un fichier de configuration, avec de nombreuses vérifications pour chaque type d'appel.
$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
...omitted... Le obligatoire mot-clé est peut-être le plus courant. Il indique que le module doit réussir le contrôle pour qu'une note globale soit rendue à l'application. Cependant, même en cas d'échec, les lignes suivantes de ce type seront toujours vérifiées. Il s'agit d'une pratique de longue date consistant à ne partager aucune raison d'un échec d'authentification. Sur les systèmes d'il y a 20 ans, il aurait peut-être été possible de deviner comment l'authentification a échoué en fonction du temps qu'il a fallu pour échouer.
Le requis le mot-clé est similaire à obligatoire en ce que la vérification doit réussir, mais en cas d'échec, elle renvoie un message "die". Exigence laisse libpam savoir que les lignes suivantes ne seront pas vérifiées, et d'informer le processus appelant du résultat global — dans ce cas, un échec.
Le suffisant le mot-clé est presque l'opposé de requis . En cas de succès, un message "done" est renvoyé et libpam va de l'avant et renvoie ses résultats globaux à l'application appelante. Les autres résultats de ce module sont ignorés et la vérification se poursuit.
Le suffisant mot-clé est courant lorsqu'il peut y avoir plusieurs façons de vérifier un critère. Par exemple, lors de la vérification d'un mot de passe, l'utilisateur peut être défini dans le /etc/passwd local et /etc/shadow fichiers, ou ils peuvent uniquement être définis dans un système central accessible avec sssd . Le pam_unix module vérifie les fichiers locaux. En cas de succès, il n'est pas nécessaire de continuer et de vérifier les services centralisés. Cependant, si l'utilisateur n'est pas défini localement, nous ne voulons pas enregistrer un échec, nous voulons ignorer le résultat et essayer le pam_sss module. Depuis le suffisant le mot-clé n'échoue jamais vraiment, il est courant d'ajouter un pam_deny obligatoire ligne après une série de suffisant lignes. Le pam_deny module échoue toujours un peu comme le /bin/false exécutable.
Le facultatif le mot-clé est similaire à suffisant en ce qu'il ignore les échecs. Cependant, en cas de succès, il agit plus comme le requis mot clé en définissant une valeur "ok" et en continuant à effectuer des vérifications supplémentaires.
Étant donné que les deux requis et suffisant peuvent être des points de sortie de la pile de modules, l'ordre dans le fichier de configuration est important. Les lignes après ces mots-clés peuvent ou non être exécutées.
Codes de retour complexes
Au-delà de la simple syntaxe des mots-clés, les codes de retour complexes sont définis avec des paires clé-valeur entre crochets. Le /etc/pam.d/system-auth le fichier a un exemple dans la section session de la syntaxe plus complexe.
$ cat /etc/pam.d/system-auth
...omitted...
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Vous pouvez trouver la syntaxe complexe correspondant à chaque mot-clé dans le pam.conf page de manuel. Le - ci-dessus est également défini dans la page de manuel. Cela indique que la journalisation peut être ignorée si le module n'est pas installé sur le système.
Quelle est la prochaine ?
Maintenant que nous pouvons parcourir quand un appel et une sortie se produisent avec libpam , l'étape suivante consiste à mieux comprendre le cas d'utilisation de chaque module. La plupart des modules ont une page de manuel qui explique l'utilisation et montre des exemples de lignes qui doivent apparaître dans le pam.d fichiers de configuration. Certains des modules font également référence à des fichiers supplémentaires dans le /etc/security annuaire. Ces fichiers sont bien commentés et ont aussi souvent leur propre page de manuel. Le pam_pwquality et pam_limits modules sont de bons exemples pour commencer.
Récapitulez
Dans le prochain article, je passerai en revue certaines des modifications apportées à l'aide de authconfig utilitaire. Si vous souhaitez passer à l'édition de fichiers vous-même et que vous disposez d'un abonnement à la formation Red Hat, consultez le chapitre sur PAM dans le cours Red Hat Security :Linux in Physical, Virtual, and Cloud (RH415).
[ Cours en ligne gratuit :Présentation technique de Red Hat Enterprise Linux. ]