PAM - indicateur de contrôle requis et suffisant


14

J'étudie le PAM et je suis un peu ignorant de la signification d'une combinaison d'indicateurs de contrôle. D'après la documentation de Red Hat, nous avons:

  • l'
    échec requis d'un tel PAM conduira finalement à l'échec de retour PAM-API, mais seulement après que les modules empilés restants (pour ce service et ce type) ont été appelés

  • requis
    comme requis, cependant, dans le cas où un tel module renvoie une panne, le contrôle est directement renvoyé à l'application.

  • un
    succès suffisant d'un tel module suffit pour satisfaire aux exigences d'authentification de la pile de modules (si un module requis antérieur a échoué, le succès de celui-ci est ignoré). Une défaillance de ce module n'est pas considérée comme fatale pour satisfaire l'application que ce type a réussi. Si le module réussit, le framework PAM renvoie immédiatement le succès à l'application sans essayer d'autres modules.

Donc, à ma connaissance, si un module requisiteéchoue, la pile entière de modules ne sera pas analysée et le contrôle sera de retour à l'application immédiatement. Si un module sufficientréussit, le reste de la pile de modules ne sera pas analysé et le contrôle sera immédiatement renvoyé à l'application. Si un module requiredéchoue, la pile entière sera analysée.

Maintenant, je ne peux pas comprendre quel sera le comportement lorsqu'un certain module requiredéchoue et qu'un autre module sufficientréussit.

Réponses:


11

PAM passe par les éléments de la pile en séquence. Il ne garde que la mémoire de l'état dans lequel il se trouve (succès ou refus, avec succès signifiant succès jusqu'à présent), pas de la façon dont il a atteint cet état.

Si un élément marqué sufficientréussit, la bibliothèque PAM arrête de traiter cette pile. Cela se produit, qu'il y ait eu des requiredéléments précédents ou non. À ce stade, PAM renvoie l'état actuel: succès si aucun requiredélément précédent n'a échoué, sinon refusé.

De même, si un élément marqué requisiteéchoue, la bibliothèque PAM arrête le traitement et renvoie un échec. À ce stade, il n'est pas pertinent de savoir si un requiredélément précédent a échoué.

En d'autres termes, cela requiredn'entraîne pas nécessairement le traitement de toute la pile. Cela signifie seulement continuer.


Mais si un requiredélément a échoué, pourquoi doit- PAMil continuer à parcourir la pile? si ça va finalement échouer de toute façon?
Mohammed Noureldin

1
@MohammedNoureldin Même si une tentative de connexion échoue, certaines choses doivent être effectuées, telles que la journalisation, l'ajout d'un délai d'expiration contre les tentatives de force brute, etc. le nom d'utilisateur échoue alors l'utilisateur est toujours invité à entrer un mot de passe.
Gilles 'SO- arrête d'être méchant'

L'ordre est l'ordre dans lequel ils sont répertoriés dans la configuration?
OrangeDog

@OrangeDog Oui. Le module répertorié sur la première ligne est exécuté, puis la deuxième ligne est exécutée (ou sautée selon le résultat de la première ligne), etc.
Gilles 'SO- arrête d'être méchant'

1

À mon avis, un requiredindicateur de contrôle doit toujours réussir pour qu'un module réussisse.

Un sufficientmodule marqué est ignoré s'il échoue. S'il réussit et qu'aucun requiredmodule signalé ci-dessus n'a échoué, aucun autre module du même type ne doit être vérifié et le module est considéré comme réussi. Donc, fondamentalement, le requireddrapeau a une priorité plus élevée que le sufficientdrapeau, mais ce dernier a la capacité d'arrêter de vérifier les autres si les précédents requiredont réussi.

Exemple:

1 auth       required     /lib/security/pam_nologin.so
2 auth       required     /lib/security/pam_securetty.so
3 auth       required     /lib/security/pam_env.so
4 auth       sufficient   /lib/security/pam_rhosts_auth.so
5 auth       required     /lib/security/pam_stack.so service=system-auth

Si les lignes 1, 2, 3 et 4 réussissent, la ligne 5 peut être ignorée et le module authréussit. Si la ligne 4 échoue, elle est ignorée et la ligne 5 est vérifiée. Si l'une des lignes 1, 2, 3 est défaillante, la ligne 4 n'est pas prise en compte.


1
Je pense que sa question est de savoir ce qui se passe si 1 échoue et 2-4 réussit. Est-ce que 5 s'exécute? Si 1 avait réussi, 5 ne serait pas exécuté. Ou en d'autres termes, est-ce que «s'arrêter après un succès suffisant» s'applique si un module requis précédent a échoué?
cjm

Non, le module d'authentification échouerait avec une telle combinaison.
dsmsk80

La question n'est pas de savoir si l'autorisation échouera. Ce sera. La question est de savoir si le module 5 fonctionnera avant que cet échec ne soit signalé à l'application.
cjm
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.