Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : services de sécurité Oracle Solaris 11 Information Library (Français) |
Partie I Présentation de la sécurité
1. Services de sécurité (présentation)
Partie II Sécurité du système, des fichiers et des périphériques
2. Gestion de la sécurité de la machine (présentation)
3. Contrôle de l'accès aux systèmes (tâches)
4. Service d'analyse antivirus (tâches)
5. Contrôle de l'accès aux périphériques (tâches)
6. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
7. Contrôle de l'accès aux fichiers (tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Attributs de sécurité dans Oracle Solaris (référence)
Affichage du contenu des profils de droits
Ordre de recherche pour les attributs de sécurité affectés
Conventions de nommage des autorisations
Exemple de granularité d'autorisation
Pouvoir de délégation dans les autorisations
Bases de données RBAC et services de noms
Commandes pour la gestion de RBAC
Commandes sélectionnées nécessitant des autorisations
Commandes d'administration pour la gestion des privilèges
Fichiers disposant d'informations sur les privilèges
Partie IV Services cryptographiques
11. Structure cryptographique (présentation)
12. Structure cryptographique (tâches)
13. Structure de gestion des clés
Partie V Services d'authentification et communication sécurisée
14. Authentification des services réseau (tâches)
17. Utilisation de Secure Shell (tâches)
19. Introduction au service Kerberos
20. Planification du service Kerberos
21. Configuration du service Kerberos (tâches)
22. Messages d'erreur et dépannage de Kerberos
23. Administration des principaux et des stratégies Kerberos (tâches)
24. Utilisation des applications Kerberos (tâches)
25. Service Kerberos (référence)
Partie VII Audit dans Oracle Solaris
Des privilèges limitant les processus sont mis en oeuvre dans le noyau et peuvent limiter les processus au niveau des commandes, des utilisateurs, des rôles ou du système.
Le tableau suivant répertorie les commandes disponibles pour gérer les privilèges.
Tableau 10-3 Commandes pour la gestion des privilèges
|
Les fichiers suivants contiennent des informations sur les privilèges.
Tableau 10-4 Fichiers contenant des informations sur les privilèges
|
L'utilisation des privilèges peut être auditée. A chaque fois qu'un processus utilise un privilège, l'utilisation du privilège est enregistrée dans la piste d'audit du jeton d'audit upriv. Lorsque les noms de privilèges font partie de l'enregistrement, leur représentation textuelle est utilisée. Les événements d'audit suivants enregistrent l'utilisation de privilèges :
AUE_SETPPRIV (événement d'audit) : l'événement génère un enregistrement d'audit lorsqu'un jeu de privilèges est modifié. L'événement d'audit AUE_SETPPRIV se trouve dans la classe pm.
AUE_MODALLOCPRIV (événement d'audit) : l'événement d'audit génère un enregistrement d'audit lorsqu'un privilège est ajouté depuis l'extérieur du noyau. L'événement d'audit AUE_MODALLOCPRIV se trouve dans la classe ad.
AUE_MODDEVPLCY (événement d'audit) : l'événement d'audit génère un enregistrement d'audit lorsque la stratégie liée au périphérique est modifiée. L'événement d'audit AUE_MODDEVPLCY se trouve dans la classe ad.
AUE_PFEXEC audit event : l'événement d'audit génère un enregistrement d'audit lorsqu'un appel est effectué à execve() avec pfexec() activé. L'événement d'audit AUE_PFEXEC se trouve dans les classes d'audit as, ex, ps et ua. Les noms des privilèges sont inclus dans l'enregistrement d'audit.
L'utilisation réussie de privilèges inclus dans le jeu de base n'est pas auditée. La tentative d'utilisation d'un privilège de base qui a été supprimé du jeu de base d'un utilisateur fait l'objet d'un audit.
Le noyau empêche l'escalade de privilèges. Une escalade de privilèges se produit lorsqu'un privilège permet à un processus de faire plus que ce à quoi il est autorisé. Pour empêcher qu'un processus acquière plus de privilèges que ceux qui lui sont accordés normalement, les modifications de système vulnérable exigent le jeu complet de privilèges. Par exemple, un fichier ou un processus détenu par root (UID=0) ne peut être modifié que par un processus ayant le jeu complet de privilèges. Le compte root n'a pas besoin de privilèges pour modifier un fichier appartenant à root. Toutefois, un utilisateur non root doit avoir tous les privilèges pour modifier un fichier appartenant à root.
De même, les opérations permettant d'accéder aux périphériques requièrent tous les privilèges du jeu effectif.
Les privilèges file_chown_self et proc_owner sont soumis à l'escalade de privilèges. Le privilège file_chown_self permet à un processus d'abandonner ses fichiers. Le privilège proc_owner permet à un processus d'examiner des processus dont il n'est pas propriétaire.
Le privilège file_chown_self est limité par la variable système rstchown. Lorsque la variable rstchown est définie sur zéro, le privilège file_chown_self est supprimé du jeu héritable initial du système et de tous les utilisateurs. Pour plus d'informations sur la variable système rstchown, reportez-vous à la page de manuel chown(1).
Le privilège file_chown_self est attribué, pour des raisons de sécurité, à une commande particulière, placée dans un profil et affectée à un rôle pour l'utiliser dans un shell de profil.
Le privilège proc_owner n'est pas suffisant pour définir un processus UID sur 0. Basculer d'un processus de n'importe quel UID à UID=0 exige tous les privilèges. Etant donné que le privilège proc_owner donne un accès illimité en lecture à tous les fichiers sur le système, le privilège est attribué, pour des raisons de sécurité, à une commande particulière, placée dans un profil et affectée à un rôle pour l'utiliser dans un shell de profil.
Attention - Le compte d'un utilisateur peut être modifié afin d'inclure le privilège file_chown_self ou proc_owner dans le jeu héritable initial de l'utilisateur. Vous devez avoir des raisons de sécurité de poids pour placer ces privilèges puissants dans le jeu de privilèges héritable pour n'importe quel utilisateur, rôle ou système. |
Pour plus de détails sur la manière d'empêcher l'escalade de privilèges pour des périphériques, reportez-vous à la section Privilèges et périphériques.
Pour s'adapter aux anciennes applications, l'implémentation de privilèges fonctionne à la fois avec le superutilisateur et les modèles de privilège. Le noyau suit automatiquement l'indicateur PRIV_AWARE, qui indique qu'un programme a été conçu pour fonctionner avec des privilèges. Prenons un processus fils qui n'est pas conscient des privilèges. Les privilèges hérités du processus parent sont disponibles dans les jeux effectif et autorisé de l'enfant. Si le processus fils définit un UID sur 0, le processus fils n'a peut-être pas toutes les capacités de superutilisateur. Les jeux effectif et autorisé du processus sont limités aux privilèges dans le jeu limite de l'enfant. Par conséquent, le jeu limite d'un processus conscient des privilèges restreint les privilèges root des processus fils qui ne sont pas conscients des privilèges.