Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : services de sécurité Oracle Solaris 11 Information Library (Français) |
Partie I Présentation de la sécurité
1. Services de sécurité (présentation)
Partie II Sécurité du système, des fichiers et des périphériques
2. Gestion de la sécurité de la machine (présentation)
3. Contrôle de l'accès aux systèmes (tâches)
4. Service d'analyse antivirus (tâches)
5. Contrôle de l'accès aux périphériques (tâches)
6. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
7. Contrôle de l'accès aux fichiers (tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Attributs de sécurité dans Oracle Solaris (référence)
Partie IV Services cryptographiques
11. Structure cryptographique (présentation)
12. Structure cryptographique (tâches)
13. Structure de gestion des clés
Partie V Services d'authentification et communication sécurisée
14. Authentification des services réseau (tâches)
Avantages de l'utilisation de PAM
Présentation de la structure PAM
Modifications apportées à la structure des modules PAM pour cette version
Planification de la mise en oeuvre PAM
Procédure d'ajout d'un module PAM
Procédure d'interdiction de l'accès rhost à partir de systèmes distants avec PAM
Procédure de journalisation de rapports d'erreur PAM
17. Utilisation de Secure Shell (tâches)
19. Introduction au service Kerberos
20. Planification du service Kerberos
21. Configuration du service Kerberos (tâches)
22. Messages d'erreur et dépannage de Kerberos
23. Administration des principaux et des stratégies Kerberos (tâches)
24. Utilisation des applications Kerberos (tâches)
25. Service Kerberos (référence)
Partie VII Audit dans Oracle Solaris
Le fichier de configuration PAM, pam.conf(4), permet de configurer les modules du service PAM pour les services de système login, rlogin, su et cron. Il incombe à l'administrateur système de gérer ce fichier. Un ordre d'entrée incorrect dans le fichier pam.conf peut entraîner des effets secondaires imprévus. Par exemple, un fichier pam.conf mal configuré peut verrouiller les utilisateurs, de manière que le mode monoutilisateur s'impose pour effectuer des réparations. La section Fonctionnement de la superposition PAM décrit comment définir l'ordre.
Le format des entrées du fichier de configuration est le suivant :
service-name module-type control-flag module-path module-options
Nom du service, par exemple, ftp, login ou passwd. Une application peut utiliser différents noms pour les services offerts par l'application. Par exemple, le démon shell sécurisé Oracle Solaris utilise les noms de services suivants : sshd-none, sshd-password, sshd-kbdint, sshd-pubkey et sshd-hostbased. Le nom de service other est un nom prédéfini, utilisé comme nom de service générique. Si aucun nom de service spécifique n'est trouvé dans le fichier de configuration, la configuration pour other est utilisée.
Type du service, c'est-à-dire auth, account, session ou password.
Rôle du module dans la détermination de la valeur intégrée de réussite ou d'échec pour le service. Les indicateurs de contrôle valides sont binding, include, optional, required, requisite et sufficient. Pour plus d'informations sur l'utilisation de ces indicateurs, reportez-vous à la section Fonctionnement de la superposition PAM.
Chemin d'accès à l'objet de bibliothèque qui met en oeuvre le service. S'il n'est pas absolu, on suppose qu'il est relatif à /usr/lib/security/$ISA/. Utilisez la macro dépendante de l'architecture $ISA pour que libpam recherche l'architecture spécifique de l'application dans le répertoire.
Options transmises aux modules de service. Une page de manuel du module décrit les options acceptées par ce module. nowarn et debug sont deux options de module typiques.
Lorsqu'une application appelle les fonctions suivantes, libpam lit le fichier de configuration /etc/pam.conf pour identifier les modules qui participent à l'opération pour ce service :
Si /etc/pam.conf ne contient qu'un seul module pour une opération pour ce service (authentification ou gestion de compte, par exemple), le résultat de ce module détermine celui de l'opération. Par exemple, l'opération d'authentification par défaut pour l'application passwd contient un module, pam_passwd_auth.so.1 :
passwd auth required pam_passwd_auth.so.1
D'autre part, si plusieurs modules sont définis pour l'opération du service, on parle de modules empilés et d'une pile PAM pour ce service. Par exemple, prenons le cas où pam.conf contient les entrées suivantes :
login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1
Ces entrées représentent un exemple de pile auth pour le service login. Pour déterminer le résultat de cette pile, les codes de résultat de chaque module requièrent un processus d'intégration. Dans le processus d'intégration, les modules sont exécutés dans l'ordre indiqué par /etc/pam.conf. Chaque code de réussite ou d'échec est intégré dans le résultat global en fonction de l'indicateur de contrôle du module. L'indicateur de contrôle peut entraîner la fin anticipée de la pile. Par exemple, un module requisite peut échouer, ou un module sufficient ou binding peut réussir. Une fois la pile traitée, tous les résultats sont regroupés en un résultat global unique, qui est transmis à l'application.
L'indicateur de contrôle précise le rôle joué par le module PAM pour déterminer l'accès au service. Les indicateurs de contrôle ont les effets suivants :
Binding : lorsque les exigences d'un module binding (obligatoire) sont satisfaites, la réussite est immédiatement renvoyée à l'application si aucun module required précédent n'a échoué. Si ces conditions sont vérifiées, aucun autre module n'est exécuté. En cas d'échec, un échec required est enregistré et le traitement des modules se poursuit.
Include : ajoute des lignes d'un autre fichier de configuration PAM à utiliser à ce stade de la pile PAM. Cet indicateur ne contrôle pas les comportements de réussite ni d'échec. Lorsqu'un nouveau fichier est lu, la pile include (inclure) PAM est incrémentée. Au terme de la vérification de la pile dans le nouveau fichier, la valeur de la pile include est décrémentée. Une fois la fin du fichier atteinte et la valeur de la pile include PAM définie sur 0, le traitement de la pile prend fin. La valeur maximale pour la pile include PAM est 32.
Optional : il n'est pas nécessaire que les exigences d'un module optional (facultatif) soient satisfaites pour que le service puisse être utilisé. En cas d'échec, un échec optional est enregistré.
Required : les exigences d'un module required (requis) doivent être satisfaites pour que le service puisse être utilisé. Un échec entraîne le renvoi d'une erreur après l'exécution des modules restants pour ce service. La réussite finale du service n'est renvoyée que si aucun module binding ou required n'a signalé d'échec.
Requisite : les exigences d'un module requisite (indispensable) doivent être satisfaites pour que le service puisse être utilisé. Un échec entraîne le renvoi immédiat d'une erreur et l'arrêt de l'exécution des modules. Tous les modules requisite pour un service doivent renvoyer un résultat positif pour que la fonction puisse renvoyer une réussite à l'application.
Sufficient : si aucun échec required précédent ne s'est produit, la réussite dans un module sufficient (suffisant) renvoie immédiatement un résultat positif à l'application et aucun autre module n'est exécuté. En cas d'échec, un échec optional est enregistré.
Les deux diagrammes suivants indiquent comment l'accès est déterminé lors du processus d'intégration. Le premier diagramme indique comment la réussite ou l'échec sont enregistrés pour chaque type d'indicateur de contrôle. Le second diagramme indique comment la valeur intégrée est déterminée.
Figure 15-2 Superposition PAM : effet des indicateurs de contrôle
Figure 15-3 Superposition PAM : détermination de la valeur intégrée
Examinez l'exemple suivant d'un service rlogin qui demande une authentification.
Exemple 15-1 Contenu partiel d'un fichier de configuration PAM standard
Le fichier pam.conf dans cet exemple comporte les éléments suivants pour les services rlogin :
# Authentication management ... # rlogin service rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_auth.so.1 ...
Lorsque le service rlogin demande une authentification, libpam exécute d'abord le module pam_rhosts_auth(5). L'indicateur de contrôle est défini sur sufficient pour le module pam_rhosts_auth. Si le module pam_rhosts_auth est en mesure d'authentifier l'utilisateur, le traitement s'arrête et la réussite est renvoyée à l'application.
Si le module pam_rhosts_auth n'est pas en mesure d'authentifier l'utilisateur, le module PAM suivant, pam_authtok_get(5) est exécuté. L'indicateur de contrôle de ce module est défini sur requisite. Si pam_authtok_get échoue, le processus d'authentification se termine et l'échec est renvoyé à rlogin.
Si pam_authtok_get réussit, les deux modules suivants, pam_dhkeys(5) et pam_unix_auth(5), sont exécutés. Les indicateurs de contrôle associés des deux modules sont définis sur required de sorte que le processus se poursuit même si un échec individuel est renvoyé. Une fois pam_unix_auth exécuté, il ne reste plus de modules pour l'authentification rlogin. A ce stade, si pam_dhkeys ou pam_unix_auth a renvoyé un échec, l'accès via rlogin est refusé à l'utilisateur.