Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide d'administration système : Services de sécurité |
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. Contrôle de l'accès aux périphériques (tâches)
5. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
6. Contrôle de l'accès aux fichiers (tâches)
7. Utilisation d'Automated Security Enhancement Tool (Tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
Contrôle d'accès basé sur les rôles (présentation)
RBAC : la solution de substitution au modèle superutilisateur
Éléments et concepts de base RBAC Oracle Solaris
Applications privilégiées et RBAC
Applications vérifiant les UID et GID
Applications vérifiant les privilèges
Applications vérifiant les autorisations
Champ d'application du service de noms et RBAC
Considérations relatives à la sécurité lors de l'affectation directe d'attributs de sécurité
Protection des processus noyau par les privilèges
Différences administratives sur un système disposant de privilèges
Privilèges et ressources du système
Comment les processus obtiennent des privilèges
Extension des privilèges d'un utilisateur ou d'un rôle
Restriction des privilèges d'un utilisateur ou d'un rôle
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Contrôle d'accès basé sur les rôles (référence)
Partie IV Services cryptographiques
13. Structure cryptographique Oracle Solaris (présentation)
14. Structure cryptographique Oracle Solaris (tâches)
15. Structure de gestion des clés Oracle Solaris
Partie V Services d'authentification et communication sécurisée
16. Utilisation des services d'authentification (tâches)
19. Utilisation d'Oracle Solaris Secure Shell (tâches)
20. Oracle Solaris Secure Shell (référence)
21. Introduction au service Kerberos
22. Planification du service Kerberos
23. Configuration du service Kerberos (tâches)
24. Messages d'erreur et dépannage de Kerberos
25. Administration des principaux et des stratégies Kerberos (tâches)
26. Utilisation des applications Kerberos (tâches)
27. Service Kerberos (référence)
Partie VII Audit Oracle Solaris
28. Audit Oracle Solaris (présentation)
29. Planification de l'audit Oracle Solaris
30. Gestion de l'audit Oracle Solaris (tâches)
La gestion des droits de processus permet de restreindre les processus au niveau de la commande, du rôle, du système ou de l'utilisateur. Oracle Solaris met en œuvre la gestion des droits de processus via des privilèges. En termes de sécurité, les privilèges diminuent le risque qu'un utilisateur ou un processus puisse disposer des capacités de superutilisateur complètes sur un système. Les privilèges et les contrôles RBAC offrent une solution de substitution intéressante au modèle superutilisateur traditionnel.
Pour plus d'informations sur le contrôle RBAC, reportez-vous à la section Contrôle d'accès basé sur les rôles (présentation) .
Pour plus d'informations sur la gestion des privilèges, reportez-vous à la section Chapitre 11Privilèges (tâches).
Pour obtenir des informations de référence sur les privilèges, reportez-vous à la section Chapitre 12Privilèges (référence).
Un privilège est un droit discret dont a besoin un processus pour réaliser une opération. Le droit est appliqué dans le noyau. Un programme qui s'exécute dans les limites du jeu de base de privilèges Oracle Solaris fonctionne dans les limites de la stratégie de sécurité système. Les programmes setuid sont des exemples de programmes qui fonctionnent en dehors des limites de la stratégie de sécurité système. Les privilèges permettent aux programmes d'éliminer la nécessité d'appeler setuid.
Les privilèges énumèrent discrètement les types d'opérations possibles sur un système. Les programmes peuvent être exécutés avec les privilèges exacts nécessaires à leur réussite. Par exemple, un programme qui définit la date et l'enregistre dans un fichier d'administration peut nécessiter les privilèges file_dac_write et sys_time. Cette capacité élimine la nécessite d'exécuter les programmes en tant que root.
Historiquement, les systèmes n'ont pas suivi le modèle de privilège. Ils ont plutôt utilisé le modèle de superutilisateur. Dans le modèle de superutilisateur, les processus s'exécutaient en tant que root ou en tant qu'utilisateur. L'action des processus utilisateur était limitée au niveau des répertoires et fichiers de l'utilisateur. Les processus root pouvaient créer des répertoires et fichiers en tout point du système. Un processus qui devait créer un répertoire en dehors du répertoire de l'utilisateur devait s'exécuter avec UID=0, c'est-à-dire, en tant que root. La stratégie de sécurité s'appuyait sur le contrôle d'accès discrétionnaire (DAC, Discretionary Access Control) pour protéger les fichiers système. Les nœuds de périphérique étaient protégés par DAC. Par exemple, les périphériques appartenant au groupe sys ne pouvaient être ouverts que par les membres du groupe sys.
Cependant, les programmes setuid, les autorisations de fichier et les comptes d'administration sont vulnérables à une utilisation abusive. Les actions qu'un processus setuid est autorisé à réaliser sont plus nombreuses qu'il n'est nécessaire au processus pour terminer son opération. Un programme setuid peut être compromis par un intrus qui s'exécute ensuite en tant qu'utilisateur root disposant de tous les pouvoirs. De même, tout utilisateur ayant accès au mot de passe root peut compromettre l'ensemble du système.
En revanche, un système appliquant la stratégie avec des privilèges permet l'instauration d'une graduation entre les capacités utilisateur et les capacités root. Un utilisateur peut se voir accorder des privilèges nécessaires à la réalisation d'activités dépassant les capacités des utilisateurs standard et root peut voir le nombre de ses privilèges actuels réduit. Avec RBAC, une commande qui s'exécute avec les privilèges peut être isolée dans un profil de droits et assignée à un utilisateur ou à un rôle. Le Tableau 8-1 résume la graduation entre les capacités utilisateur et les capacités root que le modèle RBAC plus privilèges fournit.
Le modèle de privilèges offre une plus grande sécurité que le modèle superutilisateur. Les privilèges supprimés d'un processus ne peuvent pas être exploités. Les privilèges de processus empêchent un programme ou compte d'administration d'accéder à toutes les capacités. Les privilèges de processus peuvent fournir une protection supplémentaire pour les fichiers sensibles, où les protections DAC seules peuvent être exploitées pour obtenir l'accès.
Les privilèges peuvent alors restreindre les programmes et processus aux capacités qu'ils nécessitent. Cette capacité s'appelle le principe du moindre privilège. Sur un système appliquant ce privilège, un intrus qui capture un processus n'a accès qu'aux privilèges dont dispose ce processus. Le reste du système ne peut pas être compromis.
Les privilèges sont logiquement regroupés sur la base de la zone du privilège.
Privilège FILE : les privilèges qui commencent par la chaîne file fonctionnent sur les objets du système de fichiers. Par exemple, le privilège file_dac_write remplace le contrôle d'accès discrétionnaire lors de l'écriture dans les fichiers.
Privilèges IPC : les privilèges qui commencent par la chaîne ipc remplacent les contrôles d'accès aux objets IPC. Par exemple, le privilège ipc_dac_read permet à un processus de lire une mémoire partagée distante et protégée par le contrôle DAC.
Privilège NET : les privilèges qui commencent par la chaîne net offrent l'accès à des fonctionnalités réseau spécifiques. Par exemple, le privilège net_rawaccess permet à un périphérique de se connecter au réseau.
Privilège PROC : les privilèges qui commencent par la chaîne proc permettent aux processus de modifier les propriétés restreintes du processus lui-même. Les privilèges PROC comprennent des privilèges ayant un effet très limité. Par exemple, le privilège proc_clock_highres permet à un processus d'utiliser des horloges haute résolution.
Privilège SYS : les privilèges qui commencent par la chaîne sys offrent aux processus l'accès illimité à diverses propriétés système. Par exemple, le privilège sys_linkdir permet à un processus de créer et de rompre des liens physiques vers des répertoires.
Certains privilèges ont un effet limité sur le système, d'autres un effet important. La définition du privilège proc_taskid indique son effet limité :
proc_taskid Allows a process to assign a new task ID to the calling process.
La définition du privilège file_setid indique son large effet :
net_rawaccess Allow a process to have direct access to the network layer.
La page de manuel privileges(5) contient la description de chaque privilège. La commande ppriv -lv imprime une description de chaque privilège à la sortie standard.
Un système disposant de privilèges présente plusieurs différences visibles avec un système qui n'en possède pas. Le tableau suivant énumère certaines différences.
Tableau 8-2 Différences visibles entre un système avec des privilèges et un système sans privilèges
|
À partir de la version Solaris 10 8/07, les contrôles de ressources project.max-locked-memory et zone.max-locked-memory peuvent être utilisés pour limiter la consommation mémoire des processus auxquels le privilège PRIV_PROC_LOCK_MEMORY est affecté. Ce privilège permet à un processus de verrouiller des pages dans la mémoire physique.
Si vous affectez le privilège PRIV_PROC_LOCK_MEMORY à un profil de droits, vous pouvez attribuer aux processus qui disposent de ce privilège la capacité de verrouiller la totalité de la mémoire. À titre de protection, définissez un contrôle de ressources pour empêcher l'utilisateur de ce privilège de verrouiller toute la mémoire. Pour les processus privilégiés qui s'exécutent dans une zone non globale, définissez le contrôle de ressources zone.max-locked-memory. Pour les processus privilégiés qui s'exécutent sur un système, créez un projet et définissez le contrôle de ressources project.max-locked-memory . Pour plus d'informations sur ces contrôles de ressources, reportez-vous au Chapitre 6, Contrôles des ressources (présentation) du Guide d’administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris et au Chapitre 17, Configuration des zones non globales (présentation) du Guide d’administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris.
Chaque processus dispose de quatre jeux de privilèges qui déterminent s'il peut utiliser un privilège particulier. Le noyau calcule automatiquement le jeu effectif de privilèges. Vous pouvez modifier le jeu héritable de privilèges. Un programme codé pour utiliser des privilèges peut réduire le jeu autorisé du programme. Vous pouvez réduire le jeu limite de privilèges.
Jeu de privilèges effectif ou E (Effective) : jeu de privilèges actuellement en vigueur. Un processus peut ajouter des privilèges du jeu autorisé dans le jeu effectif. Un processus peut également supprimer des privilèges de E.
Jeu de privilèges autorisés ou P (Permitted): jeu de privilèges disponible pour l'utilisation. Les privilèges peuvent être disponibles à un programme après héritage ou par affectation. Un profil d'exécution est un moyen d'affecter des privilèges à un programme. La commande setuid affecte tous les privilèges dont dispose root sur un programme. Les privilèges peuvent être supprimés du jeu autorisé, mais ils ne peuvent pas y être ajoutés. Les privilèges supprimés de P sont automatiquement supprimés de E.
Un programme conscient des privilèges supprime les privilèges qu'un programme n'utilise jamais de son jeu autorisé. De cette manière, les privilèges superflus ne peuvent pas être exploités par le programme ou un processus malveillant. Pour plus d'informations sur les programmes prenant en charge les privilèges, reportez-vous au Chapitre 2, Developing Privileged Applications du Developer’s Guide to Oracle Solaris Security.
Jeu de privilèges héritable ou I (Inheritable) : jeu de privilèges qu'un processus peut hériter d'un appel à exec. Après l'appel à exec, les jeux autorisé et effectif sont égaux, à l'exception du cas particulier d'un programme setuid.
Pour un programme setuid, après l'appel à exec, le jeu héritable est d'abord restreint par le jeu limite. Ensuite, les privilèges hérités (I), moins les privilèges qui se trouvaient dans le jeu limite (L), sont affectés à P et E pour ce processus.
Jeu de privilèges de limite ou L (Limit) : limite extérieure des privilèges disponibles à un processus et à ses fils. Par défaut, le jeu limite contient tous les privilèges. Les processus peuvent réduire le jeu limite mais ne peuvent jamais l'étendre. L est utilisé pour limiter I. Par conséquent, l limite P et E au moment de l'exécution.
Si un utilisateur s'est vu affecter un profil qui inclut un programme qui a reçu des privilèges, l'utilisateur peut généralement exécuter ce programme. Sur un système non modifié, les privilèges affectés du programme se trouvent dans le jeu limite de l'utilisateur. Les privilèges affectés au programme deviennent partie intégrante du jeu autorisé de l'utilisateur. C'est à partir d'un shell de profil que l'utilisateur doit exécuter le programme auquel des privilèges ont été affectés.
Le noyau reconnaît un jeu de privilèges de base. Sur un système non modifié, le jeu héritable initial de chaque utilisateur correspond au jeu de base défini au moment de la connexion. Vous pouvez modifier le jeu héritable initial de l'utilisateur. Vous ne pouvez pas modifier le jeu de base.
Sur un système non modifié, les jeux de privilèges de l'utilisateur à la connexion ressemble à ce qui suit :
E (Effective): basic I (Inheritable): basic P (Permitted): basic L (Limit): all
Par conséquent, au moment de la connexion, tous les utilisateurs ont le jeu de base dans leur jeu hérité, leur jeu autorisé et leur jeu effectif. Le jeu limite de l'utilisateur contient tous les privilèges. Pour ajouter des privilèges au jeu effectif de l'utilisateur, vous devez affecter un profil de droits à ce dernier. Le profil de droits doit inclure les commandes pour lesquelles vous avez ajouté les privilèges. Vous pouvez également affecter des privilèges directement à l'utilisateur ou au rôle, bien que de telles affectations de privilèges puissent comporter un risque. Pour une description des risques, reportez-vous à la section Considérations relatives à la sécurité lors de l'affectation directe d'attributs de sécurité .
Les processus peuvent hériter de privilèges. Des privilèges peuvent aussi leur être affectés. Un processus hérite des privilèges de son processus parent. Au moment de la connexion, le jeu de privilèges héritable initial détermine les privilèges disponibles pour les processus de l'utilisateur. Tous les processus fils de la connexion initiale de l'utilisateur héritent de ce jeu.
Vous pouvez également affecter directement des privilèges à des programmes, des utilisateurs et des rôles. Lorsqu'un programme requiert des privilèges, vous affectez les privilèges à l'exécutable du programme dans un profil de droits. Les utilisateurs et les rôles autorisés à exécuter le programme se voient affecter le profil qui comprend le programme. Au moment de la connexion ou lorsqu'un shell de profil est saisi, le programme s'exécute avec le privilège lorsque l'exécutable du programme est entré dans le shell de profil. Par exemple, un rôle qui inclut le profil Gestion de l'accès aux objets peut exécuter la commande chmod avec le privilège file_chown.
Lorsqu'un rôle ou un utilisateur exécute un programme auquel un privilège supplémentaire a été affecté directement, celui-ci est ajouté au jeu héritable du rôle ou de l'utilisateur. Les processus fils du programme auquel des privilèges ont été affectés héritent des privilèges de leur parent. Si le processus fils nécessite plus de privilèges que le processus parent, ces privilèges doivent lui être affectés directement.
Les programmes codés pour utiliser des privilèges sont appelés des programmes conscients des privilèges. Un programme conscient des privilèges active l'utilisation des privilèges et désactive l'utilisation des privilèges lors de l'exécution du programme. Pour réussir dans un environnement de production, le programme doit se voir affecter les privilèges qu'il active et désactive.
Pour des exemples de code prenant en charge les privilèges, reportez-vous au Chapitre 2, Developing Privileged Applications du Developer’s Guide to Oracle Solaris Security. Pour affecter des privilèges à un programme qui requiert les privilèges, voir l'Ajout de privilèges à une commande.
En votre qualité d'administrateur système, vous êtes responsable de l'affectation des privilèges. En règle générale, vous affectez les privilèges à une commande dans un profil de droits. Le profil de droits est ensuite affecté à un rôle ou à un utilisateur. La console de gestion Solaris fournit l'interface utilisateur graphique nécessaire à l'affectation des privilèges. Les privilèges peuvent également être affectés à l'aide de commandes telles que smuser et smrole . Pour plus d'informations sur l'affectation de privilèges à l'aide de l'interface utilisateur graphique, reportez-vous au Chapitre 9Utilisation du contrôle d'accès basé sur les rôles (tâches).
Les privilèges peuvent également être affectés directement à un utilisateur. Si vous estimez qu'un sous-ensemble d'utilisateurs est suffisamment responsable pour utiliser un privilège au cours de sessions, vous pouvez lui affecter directement ce privilège. Les bons candidats à l'affectation directe sont les privilèges ayant un effet limité, tels que proc_clock_highres. Les mauvais candidats à l'affectation directe sont les privilèges ayant des effets importants, tels que file_dac_write.
Les privilèges peuvent également être refusés à un utilisateur ou à un système. Procédez avec prudence lorsque vous supprimez des privilèges du jeu héritable initial ou du jeu limite d'un utilisateur ou d'un système.
Les utilisateurs et les rôles disposent d'un jeu héritable de privilèges et d'un jeu limite de privilèges. Le jeu limite ne peut pas être étendu, car il contient initialement tous les privilèges. Le jeu héritable initial peut être étendu pour les utilisateurs, les rôles et les systèmes. Un privilège qui ne figure pas dans le jeu héritable peut également être affecté à un processus.
L'affectation des privilèges par processus est le moyen le plus précis pour ajouter des privilèges. Vous pouvez augmenter le nombre des opérations privilégiées qu'un utilisateur est autorisé à effectuer en permettant à l'utilisateur d'endosser un rôle. Le rôle se voit affecter des profils qui comprennent des commandes avec des privilèges ajoutés. Lorsque l'utilisateur endosse le rôle, il reçoit le shell de profil du rôle. Lorsqu'il ouvre le shell du rôle, les commandes dans les profils du rôle s'exécutent avec les privilèges ajoutés.
Vous pouvez également affecter un profil à l'utilisateur plutôt qu'à un rôle que l'utilisateur endosse. Le profil comprend des commandes avec des privilèges ajoutés. Lorsque l'utilisateur ouvre un shell de profil, tel que pfksh, il peut exécuter les commandes dans son profil avec privilège. Dans un shell standard, les commandes ne s'exécutent pas avec des privilèges. Le processus privilégié peut s'exécuter uniquement dans un shell privilégié.
Développer le jeu héritable initial de privilèges pour des utilisateurs, des rôles ou des systèmes est une manière d'affecter des privilèges plus risquée. Tous les privilèges dans le jeu héritable figurent dans le jeu autorisé et le jeu effectif. Toutes les commandes que l'utilisateur ou le rôle tape dans un shell peuvent utiliser les privilèges affectés directement. Les privilèges affectés directement permettent à un utilisateur ou à un rôle d'effectuer facilement des opérations qui peuvent figurer en dehors des limites de leurs responsabilités administratives.
Lorsque vous ajoutez des privilèges au jeu héritable initial sur un système, tous les utilisateurs qui se connectent au système disposent d'un jeu de privilèges de base plus grand. Cette affectation directe permet à tous les utilisateurs du système d'effectuer facilement des opérations qui figurent probablement en dehors des limites des utilisateurs standard.
Remarque - Le jeu limite ne peut pas être étendu, car il contient initialement tous les privilèges.
La suppression de privilèges permet d'empêcher les utilisateurs et les rôles d'exécuter certaines tâches. Vous pouvez supprimer des privilèges du jeu héritable initial et du jeu limite. Vous devez soigneusement tester la suppression de privilèges avant de distribuer un jeu héritable initial ou un jeu limite, plus petit que le jeu par défaut. En supprimant des privilèges du jeu héritable initial, vous risquez d'empêcher les utilisateurs de se connecter. Lorsque des privilèges sont supprimés du jeu limite, un ancien programme setuid peut échouer, car il nécessite un privilège qui a été supprimé.
Les scripts sont exécutables, tout comme les commandes. Par conséquent, dans un profil de droits, vous pouvez ajouter des privilèges à un script de la même façon que vous pouvez ajouter des privilèges à une commande. Le script s'exécute avec les privilèges ajoutés lorsqu'un utilisateur ou un rôle à qui le profil a été affecté exécute le script dans un shell de profil. Si le script contient des commandes qui nécessitent des privilèges, les commandes avec les privilèges ajoutés doivent également figurer dans le profil.
Les programmes conscients des privilèges peuvent restreindre les privilèges par processus. Votre tâche en ce qui concerne un programme conscient des privilèges consiste à affecter à l'exécutable seulement les privilèges dont le programme a besoin. Vous devez ensuite tester le programme pour vérifier qu'il accomplit ses tâches correctement. Vous devez également vérifier que le programme ne fait pas une utilisation abusive des privilèges.
Le modèle de privilège utilise des privilèges pour protéger les interfaces système qui, dans le modèle de superutilisateur, ne sont protégées par des autorisations de fichier. Dans un système doté de privilèges, les autorisations de fichier sont trop faibles pour protéger les interfaces. Un privilège comme proc_owner peut remplacer les autorisations de fichier et donner ensuite l'accès complet au système.
Par conséquent, la propriété du répertoire de périphérique n'est pas suffisante pour ouvrir un périphérique. Par exemple, les membres du groupe sys ne sont plus automatiquement autorisés à accéder au périphérique /dev/ip. Les autorisations de fichier sur /dev/ip sont 0666, mais le privilège net_rawaccess est requis pour ouvrir le périphérique.
La stratégie de périphériques est contrôlée par des privilèges. La commande getdevpolicy affiche la stratégie pour chaque périphérique. La commande de configuration de périphérique devfsadm installe la stratégie de périphérique. La commande devfsadm lie les jeux de privilèges avec open pour la lecture ou l'écriture de périphériques. Pour plus d'informations, reportez-vous aux pages de manuel getdevpolicy(1M) et devfsadm(1M).
La stratégie de périphériques offre une plus grande souplesse dans l'octroi d'autorisations pour ouvrir des périphériques. Vous pouvez nécessiter d'autres privilèges ou plus de privilèges que ceux prévus par la stratégie de périphérique par défaut. Les exigences en matière de privilèges peuvent être modifiées pour la stratégie de périphérique et les propriétés du pilote. Vous pouvez modifier les privilèges lors de l'installation, de l'ajout ou de la mise à jour d'un pilote de périphérique.
Les commandes add_drv et update_drv peuvent modifier les entrées de stratégie de périphérique et les privilèges spécifiques au pilote. Vous devez exécuter un processus avec le jeu complet de privilèges pour modifier la stratégie de périphérique. Pour plus d'informations, reportez-vous aux pages de manuel add_drv(1M) et update_drv(1M).
Oracle Solaris fournit des outils pour déboguer les défaillances des privilèges. Les commandes ppriv et truss fournissent le résultat du débogage. Pour consulter des exemples, reportez-vous à la page de manuel ppriv(1). Pour connaître la procédure, reportez-vous à la section Détermination des privilèges requis par un programme.