Privilèges (présentation)

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 oeuvre 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 Utilisation des privilèges (tâches).

• Pour plus d'informations sur les privilèges, reportez-vous à la section Privilèges.

Protection des processus noyau par les privilèges

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 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 manipule des fichiers peut nécessiter les privilèges file_dac_write et file_flag_set. Ces privilèges sur le processus élimine la nécessité d'exécuter le programme 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 noeuds 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 ne peut accéder qu'aux privilèges dont dispose ce processus. Le reste du système ne peut pas être compromis.

Descriptions des privilèges

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.

D'autres groupes logiques comprennent CONTRACT, CPC, DTRACE, GRAPHICS, VIRT et WIN.

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 net_rawaccess 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.

Différences administratives sur un système disposant de privilèges

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

Privilèges et ressources du système

Dans Oracle Solaris, 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. A 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 de ressources (présentation) du manuel Administration d’Oracle Solaris 11.1 : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources et au Chapitre 16, Configuration des zones non globales (présentation) du manuel Administration d’Oracle Solaris 11.1 : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources.

Mise en oeuvre des privilèges

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 manuel Developer’s Guide to Oracle Solaris 11 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 privilèges hérités sont placés dans le jeu autorisé et le jeu effectif, lesquels deviennent alors identiques, sauf dans le 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 permet de limiter I. Par conséquent, L limite P et E au moment de exec.

  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. Si vous ne pouvez pas modifier le jeu de base, vous pouvez modifier les privilèges dont un utilisateur hérite du 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 d'un utilisateur est l'équivalent du jeu limite par défaut pour la zone globale ou non globale. 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é.

Comment les processus obtiennent des privilèges

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.

conscient des privilègesLes 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 manuel Developer’s Guide to Oracle Solaris 11 Security. Pour affecter des privilèges à un programme qui requiert des privilèges, voir l'Exemple 9-18.

Affectation de privilèges

En votre qualité d'administrateur sécurité, vous êtes responsable de l'affectation des privilèges. La meilleure pratique consiste à affecter les privilèges à une commande dans un profil de droits. Le profil de droits est ensuite affecté à un rôle ou à un utilisateur.

Des privilèges peuvent également être directement affectés à un utilisateur, un rôle ou un profil de droits. 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.

Extension des privilèges d'un utilisateur ou d'un rôle

Les utilisateurs et les rôles disposent d'un jeu héritable 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.

Vous pouvez étendre les privilèges qui sont disponibles de plusieurs manières.

• 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 être affecté à un processus de manière explicite.

• Un privilège qui ne figure pas dans le jeu héritable peut être affecté de façon explicite à un port réseau, ID utilisateur ou objet de fichier. Cette utilisation du privilège est appelée stratégie étendue.

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 affectant un rôle à l'utilisateur. Le rôle se voit affecter des profils de droits qui comprennent des commandes avec des privilèges ajoutés. Lorsque l'utilisateur prend le rôle, il reçoit le shell de profil du rôle. Lorsque les commandes du profil de droits sont saisies dans le shell du rôle, les commandes s'exécutent avec les privilèges ajoutés.

Vous pouvez également affecter un profil de droits à l'utilisateur plutôt qu'à un rôle que l'utilisateur prend. Lorsque l'utilisateur ouvre un shell de profil, tel que pfksh, il peut exécuter les commandes dans son profil de droits 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.

Afin d'atténuer ce risque, vous pouvez affecter des privilèges à des utilisateurs ou des rôles afin qu'ils fonctionnent sur un objet à la fois. Les objets possibles sont les ports réseau, les ID utilisateur et les objets de fichier. Par exemple, vous pouvez affecter le privilège file_dac_read à un utilisateur pour les fichiers du répertoire /var/core . Le privilège file_dac_read doit se trouver dans le jeu effectif du processus de l'utilisateur lors de l'application de cette stratégie étendue. Dans ce cas, l'utilisateur peut lire tous les fichiers du répertoire /var/core lorsque la stratégie étendue est affectée à cet utilisateur pour cet objet de répertoire.

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.

Restriction des privilèges d'un utilisateur ou d'un rôle

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é.

Affectation de privilèges à un script

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 de droits 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 un profil de droits affecté.

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.

Privilèges et périphériques

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, dans Oracle Solaris 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 servent à 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).

Privilèges et débogage

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. Vous pouvez également exécuter la commande dtrace. Pour plus d'informations, reportez-vous à la page de manuel dtrace(1M).