|
|
France-Français | |
|
|
 |
|
Guide d'administration Software Distributor : HP-UX 11i v1, 11i v2 et 11i v3 > Chapitre 9 Sécurité de SD-UX
Authentification interne SD-UX |
|
|
Cette section aborde les sujets suivants : La sécurité SD-UX ne remplace pas la sécurité DCE. Il offre un système de protection utilisable basé sur l'hypothèse qu'il n'existe pas de plan concerté et hostile des utilisateurs pour endommager le système. La plupart des fonctionnalités de sécurité DCE mises en œuvre par SD-UX proviennent de la bibliothèque DCE Runtime intégrée à SD-UX. Cette bibliothèque apporte des capacités DCE RPC et certains des services de protection DCE nécessaires à la compatibilité avec les ACL. Sans les services complets de protection DCE, il est impossible de prouver de manière fiable l'identité d'un utilisateur émettant un appel RPC SD-UX, même dans le cas où la source et la destination de l'appel RPC sont locales. L'appel RPC n'identifie que l'adresse de réseau du client appelant. Une des clés de la protection SD-UX consiste à déterminer les utilisateurs qui sont autorisés à participer à des opérations spécifiques. En ce qui concerne l'authentification interne SD-UX, votre identité est établie à partir des identifiants HP-UX uid, gid et noms d'hôtes. Le fait que le contrôleur SD-UX soit exécuté avec un code de répertoire racine effectif uid (car le contrôleur est un programme setuid-root ) n'a aucun effet sur votre identité qui provient pour sa part de votre véritable uid. Lorsque vous lancez un appel RPC (en tant que contrôleur SD-UX), une structure caractéristique de votre identité accompagne chacun des appels à un agent. Le contrôleur adresse le nom d'utilisateur et de groupe de la personne qui lance l'appel RPC, ainsi que le nom d'hôte du système sur lequel il est exécuté (en mode DCE, realm). Cette structure porte le nom de certificats. Les certificats se composent des éléments suivants :
Les certificats de l’utilisateur sont adressés aux paramètres RPC. L’agent destinataire de l’appel RPC utilise ces informations pour comparer les certificats d’authentification. Les programmes de contrôleur SD-UX comme swinstall ou swremove fonctionnent avec les privilèges de l'utilisateur qui les a appelés. L’agent vérifie que l’utilisateur dispose des droits requis concernant l’objet en examinant l’ACL de l’objet. Si ces droits ne sont pas donnés, l'opération échoue. Tout utilisateur peut exécuter un contrôleur sur le système, mais ses actions sont restreintes (en fonction des droits accordés dans différentes ACL d'objets). Les agents SD-UX vérifient toujours que les opérations demandées par l'utilisateur sont autorisées avant de les effectuer. Les agents et démons SD-UX sont exécutés avec les privilèges d'un superutilisateur, mais ils disposent aussi de l'identité spéciale du système hôte sur lequel ils sont exécutés. Si un agent cible adresse un appel RPC à un agent source, deux ensembles de certificats sont transmis avec l'appel :
Bien que le privilège de superutilisateur local soit nécessaire pour que l'agent procède aux opérations sur le système de fichiers local (création et suppression, gestion des ACL, etc.), ce niveau de droits n'est ni exigé, ni requis pour les opérations d'appel DCE RPC avec les autres processus SD-UX. Lorsque les agents SD-UX procèdent aux appels RPC, ils adoptent l'identité du système sur lequel ils sont exécutés plutôt que celle d'un utilisateur particulier. Outre les certificats de l’appelant, l’appel RPC reçoit une autre preuve d’authenticité. L'agent SD-UX vérifie cette preuve avant d'accepter les certificats de l'appelant. L'opération consiste à transmettre le codage d'un mot de passe secret. Le mot de passe est lu dans le fichier de secrets partagés. Ce fichier est implanté sur des systèmes dans le répertoire /var/adm/sw/security/secrets.
L’agent compare ce secret codé au secret local également codé partagé avec le système hôte contrôleur. Si les secrets ne concordent pas, l'appel n'est pas authentifié et il échoue. Les secrets sont stockés par nom d'hôte dans le fichier de secrets et ils servent à établir la confiance entre les deux systèmes. Le contrôleur sélectionne dans le fichier un secret concordant avec le nom d'hôte du système sur lequel il est exécuté. À réception d’un appel RPC du contrôleur, l’agent recherche un secret associé au système hôte du contrôleur. Par exemple, si le contrôleur est exécuté sur alma.fc.hp.com et transmet la demande d’un agent exécutée sur lehi.fc.hp.com, chacun des deux processus va rechercher le secret associé à alma.fc.hp.com (le système hôte du contrôleur) dans son fichier de secrets respectif. Voici un exemple de format de fichier de secrets partagé :
La première colonne représente le nom d’hôte du contrôleur et la seconde colonne représente le secret du contrôleur. Il existe également une disposition de secret par défaut (quicksilver dans l'exemple ci-dessus) qui doit être utilisée dans le cas où aucune concordance de nom de système n'existe dans le fichier de secrets. Cette entrée est identifiée par le pseudo-nom d'hôte par défaut. Cette entrée permet des interconnexions SD-UX ouvertes entre systèmes hôtes partageant les mêmes entrées par défaut. SD-UX est livré avec le secret -sdu- susceptible d'être changé sur votre site. Si vous modifiez un secret de système hôte, assurez-vous de le modifier pour tous les fichiers de secrets des systèmes hôtes avec lesquels vous allez travailler. Le fichier de secrets peut être produit sur un site unique, puis les copies distribuées à tous les systèmes hôtes participants.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Version imprimable |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
