Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
24 décembre 2016

htmlpdflatexmanmd




polkitd

polkitd

Service PolicyKit

   polkitd fournis le service D-Bus org.freedesktop.PolicyKit1 dans le bus de message système. Les utilisateurs ou administrateurs ne devraient jamais avoir besoin de démarrer ce service vu qu'il est démarré par dbus-daemon quand une application appèlent le service.

^
24 décembre 2016

htmlpdflatexmanmd




pkttyagent

pkttyagent

Helper d'authentification textuel

   pkttyagent est utilisé pour démarrer un agent d'authentification textuel pour le sujet spécifié par --process ou --system-bus-name. Si aucun n'est spécifié, utilise le processus parent.

   Pour être notifié quand l'agent d'authentification a été enregistré, écouter soit D-Bus ou utiliser --notify-fd pour passer le numéro d'un descripteur de fichier au programme. Ce fd sera fermé quand l'agent d'authentification est enregistré.

Valeur de retour

   Si l'agent d'authentification ne peut pas être enregistré, pkttyagent quitte avec un code de sortie de 127. Des messages de diagnostique sont affichés sur stderr.

   Si une ou plusieurs options sont malformées, pkttyagent quitte avec le code 126. Si stdin est un tty, ce man est également affiché.

   Si l'agent d'authentification a été enregistré avec succès, pkttyagent continue de fonctionner, interagissant avec l'utilisateur si nécessaire. Quand ses services ne sont plus nécessaires, le processus s'arrête.

Notes

   Vu que les PID peuvent être recyclés, l'appelant devrait toujours utiliser pid,pid-start-time en utilisant l'option --process. La valeur de pid-start-time peut être déterminé en consultant par exemple proc. Si seul pid est passé à l'option --process, pkttyagent recherche l'heure de début de lui-même.

OPTIONS

--process { pid | pid,pid-start-time} processus pour lequel enregistrer l'agent d'authentification
--system-bus-name busname Nom du sujet pour lequel enregistrer l'agent d'authentification
--notify-fd fd Permet de passer un descripteur de fichier pour connaître quand l'agent d'authentification est enregistré
--fallback Empêche l'agent d'authentification textuel de remplacer un agent d'authentification existant.
^
24 décembre 2016

htmlpdflatexmanmd




pkexec

pkexec

Exécuter une commande sous un autre utilisateur

   pkexec permet à un utilisateur autorisé d'exécuter le programmes spécifié sous un autre utilisateur. Si l'utilisateur n'est pas spécifié, utilise root.

Valeur de retour

   une fois terminé, la valeur de retour est la valeur de retour du programme. Si le processus appelant n'est pas autorisé ou qu'une autorisation ne peut pas être obtenue ou qu'une erreur s'est produite, pkexec quitte avec une valeur de retour de 127. Si l'autorisation ne peut être obtenue, pkexec quitte avec la valeur 126.

l'agent d'authentification

   pkexec, comme tout autre application PolicyKit, utilise l'agent d'authentification enregistré pour le procéssus appelant. Cependant, si aucun agent d'authentification n'est disponible, pkexec enregistre son propre agent d'authentification. Ce comportement peut être désactivé avec --disable-internal-agent.

Notes de sécurité

   Exécuter un programme sous un autre utilisateur est une opération privilégiée. Par défaut l'autorisation requise nécéssite une authentification administrative. De plus, le dialogue d'authentification présenté à l'utilisateur affiche le chemin complet du programme à exécuter dont l'utilisateur est au courant de se qu'il va se passer.


+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_needed_to_run_`/bin/bash'_____|
|__________as_the_super_user_______________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_the_super_user_is_required_to_perform_this___|
|__________action._________________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Command:_/bin/bash______________________________________|
|__Run_As:__Super_User_(root)______________________________|
|__Action:__org.freedesktop.policykit.exec_________________|
|__Vendor:__The_PolicyKit_Project__________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

   L'environnement dans lequel le programme tourne, est définis à un environnement minimal et sûr pour éviter d'injecter du code via LD_LIBRARY_PATH ou des mécanismes similaires. De plus, la variable d'environnement PKEXEC_UID est définie avec l'UID invoquant pkexec. En résultat, pkexec n'autorise pas de lancer des application X11 sous un autre utilisateur vu que $DISPLAY et $XAUTHORITY ne sont pas définis. Il y a 2 variables retenus si org.freedesktop.policykit.exec.allow_gui dans une action est définis à une valeur non-nul. C'est découragé, et utilisé uniquement pour compatibilité.

Autorisations requises

   Par défaut, org.freedesktop.policykit.exec est requis sauf si un fichier de définition d'action est présent pour le programme en question. pour exiger une autre autorisation, cela peut être spécifié en utilisant l'annotation org.freedesktop.policykit.exec.path dans une action.

Exemple

Pour spécifier un type d'autorisation nécessaire pour exécuter le programme /usr/bin/pk-example-frobnicate sous un autre utilisateur, écrire simplement une définition d'action:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC
    "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"›
‹policyconfig›
    
    ‹vendor›Examples for the PolicyKit Project‹/vendor›
    ‹vendor_url›http://hal.freedesktop.org/docs/PolicyKit/‹/vendor_url›

    ‹action id="org.freedesktop.policykit.example.pkexec.run-frobnicate"›
        ‹description›Run the PolicyKit example program Frobnicate‹/description›
        ‹description xml:lang="da"›Kør PolicyKit eksemplet Frobnicate‹/description›
        ‹message›Authentication is required to run the PolicyKit example program Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹message xml:lang="da"›Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹icon_name›audio-x-generic‹/icon_name›
        ‹defaults›
            ‹allow_any›no‹/allow_any›
            ‹allow_inactive›no‹/allow_inactive›
            ‹allow_active›auth_self_keep‹/allow_active›
        ‹/defaults›
        ‹annotate key="org.freedesktop.policykit.exec.path"›/usr/bin/pk-example-frobnicate‹/annotate›
    ‹/action›
    
‹/policyconfig›

   placer ce fichier dans /usr/share/polkit-1/actions avec un nom qui ait du sens, par exemple l'espace de nom de l'action. Noter que pkexec ne valide pas les arguments passés au programme. Dans un cas normal (où l'authentification administration est requise à chaque fois que pkexec est utilisé), ce n'est pas un problème vu que si l'administrateur est un administrateur il peut simplement lancer pkexec bash pour devenir root.

   Cependant, si une action est utilisée pour laquelle l'utilisateur peut retenir l'authorisation ( ou si l'utilisateur est implicitement autorisé), tel qu'avec pk-example-frobnicate ci-dessus, cela peut être un problème de sécurité. Donc, les programmes pour lesquels l'autorisation requise par défaut est changé, ne devraient jamais implicitement faire confiance à l'entrée utilisateur.
^
24 décembre 2016

htmlpdflatexmanmd




pkcheck

pkcheck

Vérifier si un processus est autorisé

   pkcheck est utilisé pour vérifier si un processus, est autorisé à effectuer une action.

OPTIONS

--process processus pour lequel enregistrer l'agent d'authentification
--system-bus-name Nom du sujet pour lequel enregistrer l'agent d'authentification
--detail key value Peut être spécifié plusieurs fois pour passer des détails sur l'action
--allow-user-interaction Attend pour l'authentification
--list-temp Liste toutes les autorisations temporaires pour la session courante
--revoke-temp Révoque toutes les autorisations temporaires pour la session courante.
--action-id Spécifie l'action à vérifier
--process [pid|pid,pid-start-time|pid,pid-start-time,uid] Spécifie le processus à vérifier
--enable-internal-agent Si aucun agent d'authentification n'est disponible, enregistre son agent d'authentification textuel

Valeurs de retour

   si le processu spécifié est autorisé, pkcheck quitte avec une valeur de retour de 0. Si l'autorisation résultante contient des détails, ils sont affiché sur stdout.

   Si le processus spécifié n'est pas autorisé, pkcheck quitte avec une valeur de 1 et un message de diagnostique est affiché sur stdout.

   Si le processus spécifié n'est pas autorisé parce l'agent d'authentification a été fermé par l'utilisateur, pkcheck quitte avec une valeur 3 et un message de diagnostique affiché sur stderr. Des détails sont affichés sur stdout

   Si une erreur se produit pour l'autorisation, pkcheck quitte avec une valeur de retour de 127 et un message de diagnostique est affiché sur stderr.

   Si une ou plusieurs options passées sont malformées, pkcheck quitte avec une valeur de 126. Si stdin est un tty, ce man est également affiché.
^
24 décembre 2016

htmlpdflatexmanmd




pkaction

pkaction

Obtenir des détails sur les actions enregistrées

   pkaction est utilisé pour obtenir des informations sur les actions PolicyKit.

OPTIONS

--action-id Affiche seulement l'action spécifiée
--verbose Affiche des détails
^
24 décembre 2016

htmlpdflatexmanmd




polkit

polkit

framework d'autorisation

   policyKit fournis une API d'autorisation conçue pour être utilisée par des programmes privilégiés (mécanismes) offrant un service à des programmes non privilégiés (clients) sous la forme d'un mécanisme IPC tel que D-Bus ou pipes Unix. Dans ce scénario, le mécanisme traite généralement le client n'étant pas de confiance. Pour toute requête d'un client, le mécanisme doit déterminer si la requête est autorisée ou si elle devrait refuser le service au client. En utilisant l'API PolicyKit, un mécanisme peut décharger cette décision à un tier de confiant: l'autorité PolicyKit.

   En plus d'agir comme autorité, PolicyKit permet aux utilisateurs d'obtenir une autorisation temporairement en authentifiant soit un utilisateur administratif ou le propriétaire de la session auquel appartient l'utilisateur. C'est utile pour les scénarios où un mécanisme doit vérifier que l'opérateur du système est réellement l'utilisateur ou réellement un utilisateur administratif.

Architecture système

   L'architecture système de PolicyKit est composé de l'autorité (implémenté comme un service dans D-Bus) et un agent d'authentification par session utilisateur (fournis et démarré par la session utilisateur). Additionnellement, PolicyKit support des points d'extensions - spécifiquement, les vendeurs et/ou sites peuvent écrire des extensions pour contrôler complètement la stratégie d'autorisation. Dans un diagramme block, l'architecture ressemble à ceci:


    +-------------------+
_|___Authentication__|
_|_______Agent_______|
_+-------------------+
_|_libpolkit-agent-1_|
_+-------------------+
________^__________________________________+--------+
________|__________________________________|_Client_|
________+--------------+___________________+--------+
_______________________|________________________^
_______________________|________________________|
User_Session___________|________________________|
=======================|========================|=============
System_Context_________|________________________|
_______________________|________________________|
_______________________|____________________+---+
_______________________V____________________|
_____________________/------------\_________|
_____________________|_System_Bus_|_________|
_____________________\------------/_________|
_______________________^________^___________V
_______________________|________|______+---------------------+
________+--------------+________|______|______Mechanism______|
________|_______________________|______+---------------------+
________V_______________________+----›_|_libpolkit-gobject-1_|
+------------------+___________________+---------------------+
|_org.freedesktop._|
|____PolicyKit1____|
+------------------+
|___Backends_and___|
|____Extensions____|
+------------------+

   libpolkit-gobject-1 enveloppe l'API D-Bus PolicyKit utilisant GObject. Cependant, un mécanisme peut également utiliser l'API D-Bus ou la commande pkcheck pour vérifier les autorisations.

   La librairie libpolkit-agent-1 fournis une abstraction du système d'authentification natif, par exemple pam et également des facilités d'enregistrement et de communication avec le service D-Bus PolicyKit.

   Les extensions PolicyKit et les backends d'autorité sont implémentés en utilisant libpolkit-backend-1

Agents d'authentification

   Un agent d'authentification est utilisé pour que l'utilisateur d'une session prouve qu'il est l'utilisateur ou un utilisateur administratif. Pour s'intégrer avec le reste de la session utilisateur, les agents d'authentification sont censés être fournis par la session utilisateur que l'utilisateur utilise. Par exemple, un agent d'authentification peut ressembler à:


+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__L'authentification_est_requise_pour_lancer______|
|__________des_tests_ATA_SMART_____________________________|
|__________________________________________________________|
|_________Une_application_tente_d'effectuer_une_action_____|
|_________qui_nécessite_des_privilèges._L'authentification_|
|_________super_utilisateur_est_requis_pour_effectuer______|
|_________cette_action.____________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

Si le système est configuré sans un compte root il peut vous autoriser à sélectionner un utilisateur administratif:
+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_required_to_run_ATA_SMART_____|
|__________self_tests______________________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_one_of_the_users_below_is_required_to________|
|__________perform_this_action.____________________________|
|__________________________________________________________|
|__________[[Face]_Patrick_Bateman_(bateman)_________[V]]__|
|__________________________________________________________|
|__________Password_for_bateman:_[______________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

   Les applications qui tournent pas sous un environnement de bureau peuvent ne pas avoir d'agent d'authentification associé avec lui. De telles applications peuvent utiliser le type PolkitAgentTextListener ou pkttyagent pour que l'utilisateur puisse s'authentifier en utilisant une interface textuelle.

Déclarer des actions

   Un mécanisme doit déclarer un jeu d'actions pour utiliser PolicyKit. Les actions correspondent aux opérations que les clients peuvent demander et sont définis dans des fichiers XML que le mécanisme install dans /usr/share/polkit-1/actions.

Les action PolicyKit sont en namespace et peuvent seulement contenir les caractères "[a-z][0-9].-". Chaque fichier XML peut contenir plus d'une action mais toutes les actions doivent être dans le même espace de nom et le fichier doit être nommé après l'espace de nom et doit avoir l'extension .policy. Le fichier XML doit avoir la déclaration doctype suivante:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"›

   L'élément policyconfig doit être présent exactement une fois. Les éléments qui peuvent être utilisés dans policyconfig incluent:

vendor Le nom du projet ou vendeur qui fournis les action dans le document XML.
vendor_url Une URL du projet ou vendeur qui fournis les action dans le document XML.
icon_name Un icône représentant le projet ou vendeur qui fournis les actions.
action Déclare une action. Le nom de l'action est spécifiée en utilisant l'attribut id et peuvent seulement contenir les caractères "[a-z][0-9].-"

   Les éléments qui peuvent être inclus dans les actions sont:

        description Une description de l'action
        message Le message affiché à l'utilisateur quand les accréditifs sont demandés.
        defaults Cet élément est utilisé pour spécifier des autorisation implicites au client

           Les éléments qui peuvent être utilisés dans defaults incluents:

                allow_any Autorisation implicite qui s'applique à tout client.
                allow_inactive Autorisation implicite qui s'applique aux clients dans les sessions inactives dans les consoles locales.
                allow_active Autorisation implicite qui s'applique aux clients dans les sessions actives dans les consoles locales.

                   Chaque élément allow_any, allow_inactive, et allow_active peuvent contenir les éléments suivants:

                        no non autorisé
                        yes autorisé
                        auth_self Authentification par le propriétaire de la session d'où vient le client requise
                        auth_admin Authentification par un utiliateur administratif est requis
                        auth_self_keep Comme auth_self mais l'autorisation est conservé pour une période brève.
                        auth_admin_keep Comme auth_admin mais l'autorisation est conservée pour une brève période.

        annotate Utilisé pour annoter une action avec une paire de clé/valeur. La clé est spécifiée en utilisant l'attribut clé et la valeur est spécifiée en utilisant la valeur attribut. Cet élément peut apparaître 0 ou plusieurs fois.
        vendor Utilisé pour remplacer le vendeur sur une base par action
        vendor_url Utilisé pour remplacer l'URL vendeur sur une base par action
        icon_name Utilisé pour remplacer le nom de l'icône sur une base par action

   Les éléments localization, description et message peuvent exister 0 ou plusieurs fois avec différents attributs xml:lang

   Pour lister les actions installées, utiliser la commande pkaction

Annotations connues

org.freedesktop.policykit.exec.path est utilisé par le programme pkexec fournis par PolicyKit.
org.freedesktop.policykit.imply (sa valeur est une chaîne contenant une liste séparée par un espace d'identifiants d'action). peut être utilisé pour définir des actions méta. La manière dont elles fonctionnent et que si un sujet est autorisé pour une action spécifiée, il est également autorisé pour toutes les autres action de l'annotation. Une utilisation typique est en définissant un shell avec un simple bouton lock qui devrait débloquer plusieurs actions pour des mécanismes distincts.
org.freedesktop.policykit.owner peut être utilisé pour définir un jeu d'utilisateurs qui peuvent demander si un client est autorisé à effectuer cette action. Si cette annotation n'est pas spécifiée, seul root peut vérifier si un client tournant sous un utilisateur différent est autorisé pour une action. La valeur de cette annotation est une chaîne contenant une liste séparée par des espaces d'entrées PolkitIdentity. par exemple "unix-user:42 unix-user:colord". Une utilisation typique est pour les processus qui tournent sous un utilisateur système au lieu de root.
^
19 octobre 2013

htmlpdflatexmanmd




gsasl

gsasl

CLI pour libgsasl

OPTIONS

-c, --client Agit comme client
--client-mechanism Mécanismes supportés par le client
-s, --server Agit comme serveur
--server-mechanism Mécanismes supportés par le serveur
--connect=HOSTNAME[:SERVICE] Serveur distant.
-d, --application-data Après l'authentification lis les données de stdin et le lance dans la couche de sécurité du mécanisme puis l'affiche en base64.
--imap Utilise la procédure de login style IMAP
-m, --mechanism=STRING mécanisme à utiliser
--no-client-first Empêche le client d'envoyer les info en premier (client only)
-n, --anonymous-token=STRING Token pour l'authentification anonyme, générallement l'addresse email.(ANONYMOUS only)
-a, --authentication-id=STRING Identité du propriétaire des acréditations
-z, --authorization-id=STRING Identité de demandeur
--disable-cleartext-validate Désactive la validation cleartext, force le serveur à demander le mot de passe
--enable-cram-md5-validate Valide les challenge/réponse CRAM-MD5 intéractivement
--hostname=STRING Nom du serveur avec le service requis
-p, --password=STRING Mot de passe pour l'authentification
--passcode=NUMBER Passcode pour l'authentification (SECURID only)
--quality-of-protection=‹qop-auth | qop-int | qop-conf› Protection du payload. qop-auth: pas de protection, qop-int: protection de l'intégrité, qop-conf: confidentitalité
-r, --realm=STRING Royaume
--service=STRING Nom du service requis
--service-name=STRING Nom du serveur en cas de serveur répliqué (DIGEST-MD5 only)
-x, --maxbuf=NUMBER Taille de buffer max (DIGEST-MD5 only)
--starttls Force l'utilisation de starttls
--no-starttls désactive starttls
--no-cb Ne définis pas de chanel binding
--x509-ca-file=FILE Fichier contenant les certificats des CA
--x509-cert-file=FILE Fichier contenant le certificat du client
--x509-key-file=FILE Fichier contenant la clé privée du client
--priority Chaîne de priorité de chiffrement
-Q, --QUIET, --SILENT mode silencieux
-v, --verbose mode verbeux
^
19 octobre 2013

htmlpdflatexmanmd




Cyrus SASL

Cyrus SASL

Serveur SASL de Cyrus

Composants SASL

   Le premier composant de la librairie SASL est la couche Glue. Il s'occupe des tâches de base:

- Charger les plugins
- Gère les propriétés de sécurité nécessaires de l'application pour l'aider dans le choix du mécanisme ou pour limiter les mécanismes disponibles.
- Lister les plugins disponibles au applications
- Choisir le meilleur mécanisme dans une liste pour une authentification particulière
- Router les paquets de données d'authentification entre l'application et le mécanisme choisi
- Fournir des informations sur la négociation SASL aux applications

   Il fournis également d'autres services aux plugins et applications tels que l'encodage MIME base 64, génération de nombres aléatoires, etc. Il permet également aux mécanismes et aux applications d'accéder à types spéciaux de plugin. Auxiliary Property "auxprop" qui fournis une interface de base simple et peut retourner des propriétés sur l'utilisateur tel que le mot de passe, répertoire personnel, ou adresse mail. et Username Canonicalization, qui peut fournir des manières de canoniser un nom d'utilisateur ou effectuer d'autres tâches.

Mécanisme PLAIN et mots de passe en texte clair

auxprop Vérifie les mots de passe dans userPassword fournis par une plugin de propriété auxiliaire. Par exemple, SASL est fournis avec sasldb, qui peut être utilisé pour authentifier avec des mots de passe stockés dans /etc/sasldb2.
saslauthd Permet de vérifier des mots de passe en utilisant divers mécanismes.
courrier-IMAP authdaemond Utilisé pour contacter authdaemond pour vérifier les mots de passe.

Mécanismes à secret partagé

   Cyrus SALS fournis plusieurs méthodes d'authentification basé sur un secret partagé: CRAM-MD5 et son successeur DIGEST-MD5.

Mécanismes Kerberos

   Cyrus SASL fournis 2 mécanismes qui utilisent kerberos: Kerberos_v4 et GSSAPI qui permet d'utiliser kerberos v5.

Mécanismes OTP

   Cyrus SASL support le mécanisme OTP, similaire à CRAM-MD5 et DIGEST-MD5. Ces OTP sont stockés dans /etc/sasldb2. SASL support également OPIE.

Auxiliary Properties

   SASLv2 introduit le concept de propriétés auxiliaires. C'est la capacité de rechercher des informations liées à l'authentification ou l'authorisation depuis un répertoire durant le processus d'authentification.

Fichier de configuration par défaut

   Par défaut, Cyrus SASL lit ses options depuis /usr/lib/sasl2/App.conf (où App est le nom de l'application). Les applications peuvent redéfinir comment la librairie recherche les informations de configuration.

OPTIONS

authdaemond_path (SASL library) Chemin du socket UNIX de authdaemond (défaut: /dev/null)
auto_transition (SASL library) à yes ou noplain et utilisé avec auxprop. Transferts automatiquement les users à d'autres mécanismes quand ils font une authentification plaintext réussie. à noplain, seul les secrets non plaintext sont écris. (défaut: no)
auxprop_plugin (AuxProp Plugin) Nom(s) de(s) plugin(s) auxiliaire à utiliser. (défaut: null)
canon_user_plugin (SASL library) Nom du plugin canon_user à utiliser (défaut: INTERNAL)
keytab (GSSAPI) Emplacement du fichier keytab (défaut: /etc/krb5.keytab)
ldapdb_uri (LDAPDB plugin) liste d'URI ldap
ldapdb_id (LDAPDB plugin) id d'authentification ldap
ldapdb_mech (LDAPDB plugin) mécanisme pour l'authentification
ldapdb_pw (LDAPDB plugin) password
ldapdb_rc (LDAPDB plugin) Fichier à placer dans l'environnement LDAPRC
ldapdb_starttls (LDAPDB plugin) utiliser StartTls (try, demand).
ldapdb_canon_attr (LDAPDB plugin) attribut contenant le nom canonique de l'utilisateur
log_level (SASL library) Niveau de debug (défaut: 1 (SASL_LOG_ERR))
mech_list (SASL library) liste de mécanisme à autoriser (défaut: tous)
ntlm_server (SASL library) Liste des serveurs
ntlm_v2 (SASL library) Envoyer des réponses ntlmv2 au serveur opiekeys (OPIE) Emplacement du fichier opiekeys (défaut: /etc/opiekeys)
otp_mda (OPIE) Algorithme pour l'OTP (md4, md5, sha1) (défaut: md5)
plugin_list (SASL library) Emplacement de la liste des plugins
pwcheck_method (SASL library) liste des mécanismes utilisés pour vérifier les mots de passe, utilisé par sasl_checkpass (auxprop, saslauthd, pwcheck, authdaemond, alwaystrue). (défaut: auxprop)
reauth_timeout (DIGST-MD5) Temps en minutes de cache de l'authentification pour une réauthentification rapide. défaut: 0
saslauthd_path (SASL library) Chemin vers le répertoire saslauthd, incluant le pipe /mux
sasldb_path (sasldb plugin) Chemin du fichier sasldb (défaut: /etc/sasldb2)
sql_engine (SQL plugin) Nom du moteur SQL à utiliser (mysql, pgsql, sqlite, sqlite3). défaut: mysql
sql_hostnames (SQL plugin) liste de serveurs:ports SQL
sql_user (SQL plugin) Utilisateur SQL pour l'authentification
sql_passwd (SQL plugin) Mode de passe pour l'authentification
sql_database (SQL plugin) Nom de la base de données qui contient les propriétés auxiliaires
sql_select (SQL plugin) Déclaration SELECT à utiliser pour récupérer les propriétés
sql_insert (SQL plugin) Déclaration INSERT pour créer des propriétés
sql_update (SQL plugin) Déclaration UPDATE pour mettre à jours des propriétés
sql_usessl (SQL plugin) à yes, créé une connexion sécurisée
srp_mda (SRP) Algorithme à utiliser pour les calculs SRP (md5, sha1, rmd160).
srvtab (kerberos 4) Emplacement du fichier srvtab (défaut: /etc/srvtab)

Notes sur les options auxprop sql

%U username
%p Nom de la propriété à modifier/ajouter
%r Royaume auquel l'utilisateur appartient
%v Valeur de la propriété

Exemples

sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
Va envoyer la requête suivante pour l'utilisateur bovik et le royaume madoka.surf.org.uk:
SELECT userPassword FROM user_table WHERE username = 'bovik' and realm = 'madoka.surf.org.uk';
sql_insert: INSERT INTO user_table (username, realm, %p) VALUES ('%u', '%r', '%v')
Va générer les requêtes suivante pour l'utilisateur bovik dans le royaume madoka.surf.org.uk et le userPassword "wert":
INSERT INTO user_table (username, realm, userPassword) VALUES ('bovik', 'madoka.surf.org.uk', 'wert');

Notes sur les options LDAPDB

s'active en créant /usr/lib/sasl2/slapd.conf avec:
auxprop_plugin: slapd

Exemples

ldapdb_uri: ldap://ldap.example.com
ldapdb_id: root
ldapdb_pw: secret
ldapdb_mech: DIGEST-MD5
ldapdb_canon_attr: uid
root authcid doit avoir des privilèges de proxy authorization pour tous les comptes authorisés à s'authentifier.
ldapdb_uri: ldapi://
ldapdb_mech: EXTERNAL
Cette configuration assume que le serveur LDAP est sur le même serveurs qui utilise SASL. C'est plus rapide et sécure et n'a pas besoin de stocker de user/password. slapd.conf doit mapper ces usernames en DN ldap:
sasl-regexp uidNumber=(.*)\\+gidNumber=(.*),cn=peercred,cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(&(uidNumber=$1)(gidNumber=$2))
sasl-regexp uid=(.*),cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(uid=$1)
^
19 octobre 2013

htmlpdflatexmanmd




saslauthd

saslauthd

Service qui manipule les authentifications plaintext basé sur la librarie Cyrus SASL

OPTIONS

-a authmech Spécifie le mécanime à utiliser
-O option Options spécifiques au mécanisme, incluant l'hôte à contacter
-m path Chemin du socket pour les connexions (défaut : /var/state/saslauthd) sans "/mux"
threads Nombre de threads à traiter (défaut : 5)
-s size Taille de la table de hash en Ko
-t timeout temps d'expiration du cache d'authentification en secondes
-T' Honore les restriction de connection time-of-day
-c' Active le cache des crédentials
-l' Désactive l'utilisation d'un file lock pour contrôller l'accès à accept()
-r' Combine le roaume avec le login.
-d' Mode debug

Mécanismes d'authentification

getpwent Authentifie avec un fichier password local
kerberos4 Authentification kerberos v4
kerberos5 Authentification kerberos v5
pam' Utilise PAM
rimap' Remote IMAP server.
shadow' Utilise le fichier shadow local
sasldb' Authentifie avec la base SASL
ldap' Authentifie avec un serveur LDAP
sia' Authentifie en utilisant SE Linux
^
01 septembre 2013

htmlpdflatexmanmd




rfc4422

rfc4422

Simple Authentication and Security Layer (SASL)

   SASL est un framework fournissant des services d'authentification et de sécurité de données dans des protocoles orienté connexion utilisant des mécanismes remplaçable. SASL fournis une interface structurée entre les protocoles et les mécanismes. SASL fournis également un protocole pour sécuriser les échanges. SASL est conçu pour permettre à de nouveaux protocoles de réutiliser les mécanismes existants.

   SASL fournis une couche d'abstraction entre les protocoles et les mécanismes. Pour utiliser SASL, chaque protocole fournis une méthode pour identifier le mécanisme à utiliser, une méthode pour échanger les challenges et une méthode pour la communication. Chaque mécanisme SASL définis une série de server-challenge et client-response qui fournissent les services d'authentification et de négociation de sécurisation des données.

Concept d'identité

   SASL nécessite 2 identités:

1) L'identité associé avec les accréditifs ( authentication identity )
2) L'identité qui agis en tant que ( authorization identity )

   Le client fournis ses accréditifs ( qui inclus ou implique un authentication identity) et optionnellement, une chaîne de caractère représentant l'authorization identity. Quand cette chaîne est omis ou vide, le client agis comme identité associé avec les accréditifs.

   Le serveur vérifie les accréditifs du clients et vérifie que l'identité qu'il associe avec les accréditifs du client (authorization idenity) a le droit d'agir comme authorization identity. Si une des vérifications échoue, l'échange SASL échoue.

Échange d'authentification

   Chaque échange d'authentification consiste d'un message du client vers le serveur demandant une authentification via un mécanisme particulier, suivi par une ou plusieurs paires de challenges du serveur et de réponse du client, suivis par un message du serveur indiquant la sortie de l'échange d'authentification.

Exemple d'échange

C: Request authentication exchange
S: Initial challenge
C: Initial response
‹additional challenge/response messages›
S: Outcome of authentication exchange

   Certains mécanismes spécifient que le client envoie une réponse initiale dans la requête. Plusieurs variantes sont possible.

Nommage des mécanismes

les mécanismes SASL sont nommés par des chaînes de caractère, de 1 à 20 caractère de long, en ASCII noté (ABNF) :
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
    
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)

Négociation de mécanisme

   La négociation des mécanismes est spécifique au protocole. Généralement, un protocole spécifie que le serveur avertis le client des mécanismes disponibles et supportés. Le client choisira le meilleur protocole de cette liste qu'il supporte.

Demande d'échange d'authentification

   L'échange d'authentification est initié par le client en demandant une authentification via le mécanisme qu'il spécifie. Le client envoie une message contenant le nom du mécanisme au serveur. Les particularité du message sont spécifiques au protocole. Noter que le nom du mécanisme n'est pas protégé par le mécanisme.

Challenges and Responses

   Les challenges et réponse sont imbriqués dans des messages de protocole. Le mécanisme peut être:

- Authentifier le client auprès du serveur
- authentifier le serveur auprès du client
- Transférer une chaîne authorization identity
- Négocier une couche de sécurité
- Fournir d'autres services.

   La négociation de couche de sécurité implique la négociation de services de sécurité à fournir dans la couche et comment ces services sont fournis. Après avoir reçu une requête d'authentification ou une réponse d'un client, le serveur peut fournir un challenge, annuler l'échange, ou indiquer la sortie de l'échange. Après avoir reçu un challenge, un mécanisme client peut fournir une réponse ou annuler l'échange.

Chaîne d'identité d'authorisation

   Cette chaîne est une séquence de caractères unicode représentant l'identité qui qui agis en tant que. Si cette chaîne est absente, le demandeur agis en tant qu'identité que le serveur associe avec les accréditifs du client. Une chaîne non vide indique que le client souhaite agir en tant qu'identité représentée par la chaîne.

Annuler l'échange

   Un client ou un serveur peut annuler l'échange.

Fin de l'authentification

   La conclusion de l'échange, le serveur envoie un message spécifique au protocole, au client indiquant la sortie de l'échange. La sortie est un échec si:

- L'échange d'authentification a échoué pour une quelconque raison
- Les accréditifs du client n'ont pu être vérifiés
- Le serveur ne peut associer une identité avec les accréditifs du client
- L'authorization Identity fournie est mal formaté
- L'identité associé avec les accréditifs du client n'est pas autorisé à agir en tant qu'authorization identity
- La couche sécurité demandée (ou son absence) n'est pas disponible et n'est pas utilisable par le client et/ou le serveur

   Le protocole peut inclure des données additionnelles dans le message.

Couches de sécurité

   Les mécanismes SASL peuvent offrir une grande variété de services dans les couches de sécurité, incluant l'intégrité des données et la confidentialité des données. Si la couche de sécurité est négociée dans l'échange, la couche n'est installée par le serveur qu'après le message de sortie d'échange.

Authentification multiple

   Sans être explicitement permis dans le protocole, seul un échange d'authentification réussis peut se produire dan une sessions. Quand plusieurs authentifications sont permis, en aucun cas il ne peut y avoir plusieurs couche de sécurité simultanés. Si une couche de sécurité est effective, et qu'une seconde négociation sélectionne une autre couche de sécurité, la seconde couche remplace la première.

Protocol requirements

   Pour qu'un protocole offre des services SASL, ses spécifications doivent fournir les informations suivantes:

1) un nom de service, à sélectionner du registre de services pour la forme de nom de service basé sur l'hôte GSSAPI.
2) Détail des négociations de mécanisme que le protocole fournis.
3) Définition des messages nécessaires pour l'échange d'authentification
4) Décrire la syntaxe de chaîne d'authorization identity non-vide
5) Détailler les facilité que le protocole fournis qui permettent au client/serveur d'annuler un échange
6) Identifier précisément où les couches de sécurité nouvellement négociée prenent effet.
7) Si le protocole supporte d'autres couche de sécurité tel que TLS, la spécification doit décrire l'ordre dans lequel les couches de sécurité sont appliquées dans les données du protocole
8) indiquer si le protocole supporte l'authentification multiple

Mechanism requirement

   Les spécification des mécanisme doivent fournir les informations suivantes:

1) le nom du mécanisme
2) Si le mécanisme est client-first ou server-first.
3) si le serveur doit fournir des données additionnelles en indiquant une sortie réussie
4) Si le mécanisme est capable de transférer l'authorization identity
5) Si le mécanisme offre une couche de sécurité
6) si la technologie cryptographique utilisée supporte l'intégrité des données