Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Administration d'Oracle Solaris 11.1 : Services de sécurité Oracle Solaris 11.1 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. Vérification de l'intégrité des fichiers à l'aide de BART (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)
Affichage et utilisation des valeurs par défaut RBAC (tâches)
Affichage et utilisation des valeurs par défaut RBAC (liste des tâches)
Affichage de tous les attributs de sécurité définis
Affichage des droits qui vous sont affectés
Modification des attributs de sécurité d'un utilisateur
Utilisation de vos droits d'administration
Personnalisation RBAC pour votre site (tâches)
Configuration initiale RBAC (liste des tâches)
Planification de votre implémentation RBAC
Création d'un profil de droits
Clonage et modification d'un profil de droits système
Gestion de RBAC (liste des tâches)
Modification du mot de passe d'un rôle
Modification des attributs de sécurité d'un rôle
Réorganisation des attributs de sécurité affectés
Limitation d'un administrateur aux droits affectés de manière explicite
Octroi à un utilisateur de l'autorisation d'utiliser son propre mot de passe pour prendre un rôle
Modification du rôle root en utilisateur
Utilisation des privilèges (tâches)
Création d'une liste des privilèges sur le système
Détermination des privilèges qui vous sont attribués directement
Détermination des commandes privilégiées que vous pouvez exécuter
Détermination de privilèges sur un processus
Détermination des privilèges requis par un programme
Application d'une stratégie de privilège étendue à un port
Exécution d'un script shell avec des commandes privilégiées
10. Attributs de sécurité dans Oracle Solaris (référence)
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. Utilisation de modules d'authentification enfichables
15. Utilisation de Secure Shell
17. Utilisation de l'authentification simple et de la couche de sécurité
18. Authentification des services réseau (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
La configuration initiale de RBAC inclut la création d'utilisateurs qui peuvent prendre des rôles spécifiques, créer des rôles et les affecter aux utilisateurs appropriés.
Utilisez la liste des tâches ci-dessous pour planifier et implémenter initialement RBAC sur votre site. Certaines tâches sont triées.
|
RBAC peut faire partie intégrante de la façon dont une entreprise gère ses sources d'informations. La planification requiert une connaissance approfondie des fonctionnalités de RBAC et des exigences en matière de sécurité de votre organisation.
Remarque - Des droits par défaut sont affectés dans le fichier /etc/security/policy.conf .
Lisez la section Contrôle d'accès basé sur les rôles (présentation). L'utilisation de RBAC pour administrer un système est très différente de l'utilisation des pratiques administratives UNIX conventionnelles. Pour vous familiariser avec les concepts RBAC avant de commencer l'implémentation, reportez-vous au Chapitre 10, Attributs de sécurité dans Oracle Solaris (référence).
La stratégie de sécurité de votre entreprise détaille les menaces potentielles pour votre système, mesure les risques de chaque menace et fournit des stratégies pour les contrer. L'isolation des tâches liées à la sécurité par le biais de RBAC peut être une partie de la stratégie. Bien que vous puissiez utiliser les configurations RBAC en l'état, vous pouvez être amené à les personnaliser pour adhérer à la stratégie de sécurité en vigueur.
En fonction de vos besoins en matière de sécurité, vous pouvez utiliser différents degrés de RBAC, comme suit :
Root en tant que rôle : cette méthode est fournie par défaut. Elle empêche tout utilisateur de se connecter en tant que root. Au lieu de cela, un utilisateur doit se connecter à l'aide de la connexion qui leur est affectée avant d'prendre le rôle root.
Rôles discrets : cette méthode crée des rôles qui sont basés sur des profils de droits fournis. Les rôles peuvent être affectés selon le niveau de responsabilité, l'étendue de la tâche et le type de tâche. Par exemple, le rôle d'administrateur système peut effectuer un grand nombre de tâches que le superutilisateur peut effectuer, tandis que le rôle de gestion IPsec réseau peut gérer IPsec.
Vous pouvez également séparer les responsabilités de sécurité des autres responsabilités, le rôle de gestion des utilisateurs peut créer des utilisateurs, tandis que le rôle de sécurité des utilisateurs peut affecter les attributs de sécurité, tels que les rôles et les profils de droits. Cependant, le rôle de sécurité des utilisateurs ne peut pas créer un utilisateur, et le rôle de gestion des utilisateurs ne peut pas affecter un profil de droits à un utilisateur.
Aucun rôle root : pour utiliser cette méthode, vous devez modifier la configuration par défaut du système. Dans cette configuration, tout utilisateur connaissant le mot de passe pour root peut se connecter et modifier le système. Vous ne pouvez pas connaître l'identité de l'utilisateur ayant agi en tant que superutilisateur.
Passez en revue les capacités des rôles recommandés et leurs profils de droits par défaut. Les profils de droits par défaut permettent aux administrateurs de configurer un rôle recommandé en utilisant un seul profil.
Pour examiner de manière plus approfondie les profils de droits, procédez de l'une des manières suivantes :
Affichez les profils de droits disponibles sur votre système à l'aide de la commande getent prof_attr.
Dans ce guide, reportez-vous à la section Profils de droits pour obtenir le résumé de certains profils de droits habituels.
Recherchez d'autres applications ou familles d'applications sur votre site susceptibles de bénéficier d'un accès limité. Les applications affectant la sécurité, pouvant entraîner des problèmes de déni de service ou nécessitant une formation d'administrateur système particulière constituent de bons candidats pour RBAC. Vous pouvez personnaliser des rôles et des profils de droits pour gérer les exigences de sécurité de votre organisation.
Vérifiez si un profil de droits existant peut traiter cette tâche ou si un autre profil de droits doit être créé.
Remarque - Les profils de droits Media Backup (sauvegarde des médias) et Media Restore (restauration des médias) fournissent un accès à l'intégralité du système de fichiers root. Par conséquent, ces profils de droits sont affectés aux utilisateurs de confiance uniquement. Vous pouvez également choisir de ne pas affecter ces profils de droits. Par défaut, seul le rôle root est autorisé à sauvegarder et restaurer.
Choisissez si le profil de droits pour cette tâche doit être attribué à un rôle existant ou si un nouveau rôle doit être créé. Si vous utilisez un rôle existant, assurez-vous que les profils de droits d'origine du rôle sont appropriés pour les utilisateurs affectés à ce rôle. Classez le nouveau profil de droits de sorte que les commandes s'exécutent avec leurs privilèges requis. Pour plus d'informations sur le classement, reportez-vous à la section Ordre de recherche pour les attributs de sécurité affectés.
Selon le principe du moindre privilège, vous devez affecter des utilisateurs à des rôles adaptés à leur niveau de confiance. Lorsque vous empêchez les utilisateurs d'effectuer des tâches qu'ils n'ont pas besoin d'effectuer, vous réduisez les problèmes potentiels.
Les rôles peuvent être créés localement et dans un référentiel LDAP.
Avant de commencer
Pour créer un rôle, vous devez vous connecter en tant qu'administrateur disposant du profil de droits User Management (gestion des utilisateurs). Pour affecter des attributs de sécurité au rôle, y compris le mot de passe initial, vous devez vous connecter en tant qu'administrateur disposant du profil de droits User Security (sécurité des utilisateurs). Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
Pour connaître les restrictions sur les chaînes acceptables, reportez-vous à la page de manuel roleadd(1M).
# roleadd [-e expire] [-f inactive] [-s shell] [-m] [-S repository] \ [-A authorization-list] [-P profile-list] [-K key=value] rolename
Astuce - Lorsque le nom du rôle reflète le nom d'un profil de droits, vous pouvez facilement comprendre l'objectif de ce rôle. Par exemple, affectez le profil de droits Audit Review (vérification d'audit) au rôle auditreview pour permettre au rôle de lire, de filtrer et d'archiver des enregistrements d'audit.
Les arguments RBAC de cette commande sont similaires aux arguments de la commande usermod, comme décrit dans la page de manuel user_attr(4) et l'Étape 1 in Modification des attributs de sécurité d'un utilisateur. Par exemple, la commande suivante crée un rôle d'administrateur des utilisateurs local et un répertoire d'accueil.
# roleadd -c "User Administrator role, local" -s /usr/bin/pfbash \ -m -K profiles="User Security,User Management" useradm 80 blocks # ls /export/home/useradm local.cshrc local.login local.profile
# passwd -r files useradm Password: <Type useradm password> Confirm Password: <Retype useradm password> #
Remarque - En règle générale, un compte de rôle est affecté à plusieurs utilisateurs. Par conséquent, un administrateur crée généralement un mot de passe du rôle et fournit aux utilisateurs le mot de passe du rôle hors bande.
Pour connaître la procédure, reportez-vous à la section Attribution de rôle et à l'Exemple 9-14.
Exemple 9-11 Création d'un rôle d'administrateur des utilisateurs dans le référentiel LDAP
Dans cet exemple, le site de l'administrateur utilise un référentiel LDAP. En exécutant la commande suivante, l'administrateur crée un rôle d'administrateur des utilisateurs dans LDAP.
# roleadd -c "User Administrator role, LDAP" -s /usr/bin/pfbash \ -m -S ldap -K profiles="User Security,User Management" useradm
Exemple 9-12 Création de rôles pour la séparation des tâches
Dans cet exemple, le site de l'administrateur utilise un référentiel LDAP. En exécutant les commandes suivantes, l'administrateur crée deux rôles. Le rôle usermgt peut créer des utilisateurs, leur attribuer des répertoires d'accueil et effectuer d'autres tâches non liées à la sécurité. Le rôle usermgt ne peut pas affecter de mots de passe ou d'autres attributs de sécurité. Le rôle usersec ne peut pas créer d'utilisateurs, mais peut affecter des mots de passe et modifier d'autres attributs de sécurité.
# roleadd -c "User Management role, LDAP" -s /usr/bin/pfbash \ -m -S ldap -K profiles="User Management" usermgt # roleadd -c "User Security role, LDAP" -s /usr/bin/pfbash \ -m -S ldap -K profiles="User Security" usersec
Exemple 9-13 Création d'un rôle de sécurité des dispositifs et des fichiers
Dans cet exemple, l'administrateur crée un rôle de sécurité des dispositifs et des fichiers pour ce système :
# roleadd -c "Device and File System Security admin, local" -s /usr/bin/pfbash \ -m -K profiles="Device Security,File System Security" devflsec
Cette procédure permet d'attribuer un rôle à un utilisateur, redémarre le démon cache du nom, puis affiche la manière dont l'utilisateur peut prendre le rôle.
Avant de commencer
Vous avez ajouté un rôle et lui avez attribué un mot de passe, comme indiqué à la section Création d'un rôle.
Pour modifier la plupart des attributs de sécurité d'un utilisateur, y compris le mot de passe, vous devez vous connecter en tant qu'administrateur disposant du profil de droits User Security (sécurité des utilisateurs). Pour modifier les indicateurs d'audit d'un utilisateur, vous devez prendre le rôle root. Pour modifier d'autres attributs, vous devez vous connecter en tant qu'administrateur disposant du profil de droits User Management (gestion des utilisateurs). Le rôle root peut modifier tous les attributs d'un utilisateur. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
usermod [-S repository] [RBAC-arguments] login
Par exemple, attribuez le rôle à un utilisateur local :
# usermod -R +useradm jdoe-local
Les modifications sont prises en compte à la prochaine connexion de l'utilisateur.
Pour connaître les options de la commande usermod, reportez-vous à la page de manuel usermod(1M) ou à la description des options de la commande rolemod à l'Étape 1 in Modification des attributs de sécurité d'un utilisateur.
Exemple 9-14 Création et attribution d'un rôle pour administrer la cryptographie
Dans cet exemple, l'administrateur sur un réseau LDAP crée un rôle pour administrer la structure cryptographique et affecte le rôle à l'UID 1111.
# roleadd -c "Cryptographic Services manager" \ -g 14 -m -u 104 -s /usr/bin/pfksh \ -S ldap -K profiles="Crypto Management" cryptmgt # passwd cryptmgt New Password: <Type cryptmgt password> Confirm password: <Retype cryptmgt password> # usermod -u 1111 -R +cryptmgt
L'utilisateur avec l'UID 1111 se connecte, puis prend le rôle et affiche les attributs de sécurité affectés.
% su - cryptmgt Password: <Type cryptmgt password> Confirm Password: <Retype cryptmgt password> $ profiles -l Crypto Management /usr/bin/kmfcfg euid=0 /usr/sbin/cryptoadm euid=0 /usr/sfw/bin/CA.pl euid=0 /usr/sfw/bin/openssl euid=0 $
Pour plus d'informations sur la structure cryptographique, reportez-vous au Chapitre 11, Structure cryptographique (présentation). Pour l'administration de la structure, reportez-vous à la rubrique Administration de la structure cryptographique (liste des tâches).
Les actions qu'un rôle effectue peuvent faire l'objet d'un audit. Le nom de connexion de l'utilisateur qui prend le rôle, le nom de rôle, ainsi que l'action que le rôle effectue sont inclus dans l'enregistrement d'audit. L'événement d'audit 116:AUE_PFEXEC:execve(2) with pfexec enabled:ps,ex,ua,as capture les actions des rôles. En présélectionnant l'une des classes as, ex, ps, ou ua, les actions du rôle sont audités.
Avant de commencer
Pour configurer l'audit, vous devez vous connecter en tant qu'administrateur disposant du profil de droits Audit Configuration (configuration d'audit). Pour activer ou actualiser le service d'audit, vous devez vous connecter en tant qu'administrateur disposant du profil de droits Audit Control (contrôle d'audit). Le rôle root peut effectuer toutes les tâches de cette procédure. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
Pour obtenir des informations de planification, reportez-vous au Chapitre 27, Planification de l'audit.
# auditconfig -getflags
Si l'une des classes as, ex, ps, ou ua est présélectionnée, les actions du rôle sont auditées. Si ce n'est pas le cas, ajoutez l'un de ces classes aux classes existantes.
# auditconfig -setflags existing preselections,as
# auditconfig -setflags as
Dans cet exemple, l'administrateur choisit la classe as. Cette classe comprend d'autres événements d'audit. Pour afficher les événements d'audit inclus dans une classe, utilisez la commande auditrecord, comme illustré dans l'Exemple 28-28.
# audit -s
Vous pouvez créer ou modifier un profil de droits lorsque les profils de droits fournis ne contiennent pas l'ensemble des attributs de sécurité dont vous avez besoin. Pour plus d'informations sur les profils de droits, reportez-vous à la section Profils de droits RBAC.
Avant de commencer
Pour créer un profil de droits, vous devez vous connecter en tant qu'administrateur disposant du profil de droits File Security (sécurité des fichiers). Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
# profiles -p [-S repository] profile-name
Vous êtes invité à saisir une description.
Utilisez la sous-commande set pour les propriétés de profil qui possèdent une valeur unique, comme set desc. Utilisez la sous-commande add pour les propriétés qui possèdent plusieurs valeurs, comme add cmd.
Par exemple, la commande suivante crée le profil de droits PAM personnalisé dans Assignation d'une nouvelle stratégie des droits à tous les utilisateurs de manière interactive. Le nom est raccourci à des fins d'affichage.
# profiles -p -S LDAP "Site PAM LDAP" profiles:Site PAM LDAP> set desc="Profile which sets pam_policy=ldap" ...LDAP> set pam_policy=ldap ...LDAP> commit ...LDAP> end ...LDAP> exit
Exemple 9-15 Création d'un profil de droits pour les utilisateurs Sun Ray
Dans cet exemple, l'administrateur crée un profil de droits pour les utilisateurs Sun Ray dans le référentiel LDAP. L'administrateur a déjà créé une version Sun Ray du profil de droits Basic Solaris User (utilisateur Solaris de base), et a supprimé tous les profils de droits du fichier policy.conf sur le serveur Sun Ray.
# profiles -p -S LDAP "Sun Ray Users" profiles:Sun Ray Users> set desc="For all users of Sun Rays" ... Ray Users> add profiles="Sun Ray Basic User" ... Ray Users> set defaultpriv="basic,!proc_info" ... Ray Users> set limitpriv="basic,!proc_info" ... Ray Users> end ... Ray Users> exit
L'administrateur vérifie le contenu.
# profiles -p "Sun Ray Users" Found profile in LDAP repository. profiles:Sun Ray Users> info name=Sun Ray Users desc=For all users of Sun Rays defaultpriv=basic,!proc_info, limitpriv=basic,!proc_info, profiles=Sun Ray Basic User
Exemple 9-16 Suppression d'un privilège de base d'un profil de droits
Dans l'exemple suivant, après des tests approfondis, l'administrateur de la sécurité supprime un autre privilège de base du profil de droits Sun Ray Users (utilisateurs Sun Ray). Dans l'Exemple 9-15, l'administrateur a supprimé un privilège. Le profil de droits est modifié pour supprimer deux privilèges de base. Les utilisateurs auxquels ce profil est affecté ne peuvent examiner aucun processus hors de leur session en cours, ni ajouter une autre session.
$ profiles -p "Sun Ray Users" profiles:Sun Ray Users> set defaultpriv="basic,!proc_session,!proc_info" profiles:Sun Ray Users> end profiles:Sun Ray Users> exit
Exemple 9-17 Suppression de privilèges du jeu limite d'un profil de droits
Dans l'exemple suivant, après des tests approfondis, l'administrateur de la sécurité supprime deux privilèges limites du profil de droits Sun Ray Users (utilisateurs Sun Ray).
$ profiles -p "Sun Ray Users" profiles:Sun Ray Users> set limitpriv="all,!proc_session,!proc_info" profiles:Sun Ray Users> end profiles:Sun Ray Users> exit
Exemple 9-18 Création d'un profil de droits qui inclut des commandes privilégiées
Dans cet exemple, l'administrateur de la sécurité ajoute des privilèges à une application dans un profil de droits créé par l'administrateur. L'application est consciente des privilèges.
# profiles -p SiteApp profiles:SiteApp> set desc="Site application" profiles:SiteApp> add cmd="/opt/site-app/bin/site-cmd" profiles:SiteApp:site-cmd> add privs="proc_fork,proc_taskid" profiles:SiteApp:site-cmd> end profiles:SiteApp> exit
Pour vérifier, l'administrateur sélectionne la commande site-cmd.
# profiles -p SiteApp "select cmd=/opt/site-app/bin/site-cmd; info;end" Found profile in files repository. id=/opt/site-app/bin/site-cmd privs=proc_fork,proc_taskid
Voir aussi
Pour dépanner l'affectation d'attributs de sécurité, reportez-vous à la section Dépannage de RBAC et de l'affectation de privilèges. Pour plus d'informations, reportez-vous à la section Ordre de recherche pour les attributs de sécurité affectés.
Les profils de droits fournis par Oracle Solaris sont en lecture seule. Vous pouvez cloner un profil de droits fourni à des fins de modification si son ensemble d'attributs de sécurité est insuffisant. Par exemple, vous pouvez ajouter l'autorisation solaris.admin.edit/ path-to-system-file à un profil de droits fourni.
Avant de commencer
Pour créer ou modifier un profil de droits, vous devez vous connecter en tant qu'administrateur disposant du profil de droits File Security (sécurité des fichiers). Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
# profiles -p [-S repository] existing-profile-name
Ajoutez le profil de droits existant en tant que profil de droits supplémentaire, puis ajoutez les améliorations. Reportez-vous à l'Exemple 9-19.
Ensuite, renommez-le et apportez les modifications. Pour consulter un exemple, reportez-vous à l'Exemple 9-20.
Ajoutez ou supprimez des profils de droits supplémentaires, des autorisations et d'autres attributs de sécurité.
Exemple 9-19 Clonage et optimisation du profil de droits Network IPsec Management (gestion IPsec du réseau)
Dans cet exemple, l'administrateur ajoute plusieurs autorisations solaris.admin.edit à un profil de droits Site IPsec Management (gestion IPsec du site).
L'administrateur vérifie que le profil de droits Network IPsec Management ne peut pas être modifié.
# profiles -p "Network IPsec Management" profiles:Network IPsec Management> add auths="solaris.admin.edit/etc/hosts" Cannot add. Profile cannot be modified
Ensuite, il crée un profil de droits incluant le profil Network IPsec Management.
# profiles -p "Total IPsec Mgt" ... IPsec Mgt> set desc="Network IPsec Mgt plus edit authorization" ... IPsec Mgt> add profiles="Network IPsec Management" ... IPsec Mgt> add auths="solaris.admin.edit/etc/hosts" ... IPsec Mgt> add auths="solaris.admin.edit/etc/inet/ipsecinit.conf" ... IPsec Mgt> add auths="solaris.admin.edit/etc/inet/ike/config" ... IPsec Mgt> add auths="solaris.admin.edit/etc/inet/secret/ipseckeys" ... IPsec Mgt> end ... IPsec Mgt> exit
L'administrateur vérifie le contenu.
# profiles -p "Total IPsec Mgt" info name=Total IPsec Mgt desc=Network IPsec Mgt plus edit authorization auths=solaris.admin.edit/etc/hosts, solaris.admin.edit/etc/inet/ipsecinit.conf, solaris.admin.edit/etc/inet/ike/config, solaris.admin.edit/etc/inet/secret/ipseckeys profiles=Network IPsec Management
Exemple 9-20 Clonage et suppression des attributs de sécurité d'un profil de droits
Dans cet exemple, l'administrateur sépare la gestion des propriétés du service VSCAN de la capacité à activer et désactiver le service.
Tout d'abord, l'administrateur répertorie le contenu du profil de droits fourni par Oracle Solaris.
% profiles -p "VSCAN Management" info name=VSCAN Management desc=Manage the VSCAN service auths=solaris.smf.manage.vscan,solaris.smf.value.vscan, solaris.smf.modify.application help=RtVscanMngmnt.html
Ensuite, l'administrateur crée un profil de droits pour activer et désactiver le service.
# profiles -p "VSCAN Management" profiles:VSCAN Management> set name="VSCAN Control" profiles:VSCAN Control> set desc="Start and stop the VSCAN service" ... VSCAN Control> remove auths="solaris.smf.value.vscan" ... VSCAN Control> remove auths="solaris.smf.modify.application" ... VSCAN Control> end ... VSCAN Control> exit
Ensuite, l'administrateur crée un profil de droits pouvant modifier les propriétés du service.
# profiles -p "VSCAN Management" profiles:VSCAN Management> set name="VSCAN Properties" profiles:VSCAN Properties> set desc="Modify VSCAN service properties" ... VSCAN Properties> remove auths="solaris.smf.manage.vscan" ... VSCAN Properties> end ... VSCAN Properties> exit
L'administrateur vérifie le contenu des nouveaux profils de droits.
# profiles -p "VSCAN Control" info name=VSCAN Control desc=Start and stop the VSCAN service auths=solaris.smf.manage.vscan # profiles -p "VSCAN Properties" info name=VSCAN Properties desc=Modify VSCAN service properties auths=solaris.smf.value.vscan,solaris.smf.modify.application
Voir aussi
Pour dépanner l'affectation d'attributs de sécurité, reportez-vous à la section Dépannage de RBAC et de l'affectation de privilèges. Pour plus d'informations, reportez-vous à la section Ordre de recherche pour les attributs de sécurité affectés.
Vous pouvez créer une autorisation lorsque les autorisations fournies ne couvrent pas les autorisations dont vous avez besoin. Pour en savoir plus sur les autorisations, reportez-vous à la section Autorisations RBAC.
Avant de commencer
Vous avez défini et utilisé l'autorisation dans le programme que vous protégez. Pour obtenir des instructions, reportez-vous au manuel Developer’s Guide to Oracle Solaris 11 Security et à la section About Authorizations du manuel Developer’s Guide to Oracle Solaris 11 Security.
Par exemple, créez le fichier d'aide d'une autorisation pour permettre à l'utilisateur de modifier les données dans une application.
# pfedit /docs/helps/NewcoSiteAppModData.html <HTML> -- Copyright 2012 Newco. All rights reserved. -- NewcoSiteAppModData.html --> <HEAD> <TITLE>NewCo Modify SiteApp Data Authorization</TITLE> </HEAD> <BODY> The com.newco.siteapp.data.modify authorization authorizes you to modify existing data in the application. <p> Only authorized accounts are permitted to modify data. Use this authorization with care. <p> </BODY> </HTML>
Par exemple, créez l'autorisation com.newco.siteapp.data.modify sur le système local.
# auths add -t "SiteApp Data Modify Authorized" \ -h /docs/helps/NewcoSiteAppModData.html com.newco.siteapp.data.modify
Vous pouvez ensuite ajouter l'autorisation à un profil de droits et attribuez ce dernier à un rôle ou un utilisateur.
Exemple 9-21 Ajout d'autorisations à un profil de droits
Dans cet exemple, l'administrateur ajoute une autorisation qu'une application de site vérifie avant d'autoriser un utilisateur à exécuter l'application.
Après avoir créé l'autorisation, l'administrateur de sécurité ajoute l'autorisation com.newco.siteapp.data.modify aux droits existants. L'administrateur a créé le profil de l'Exemple 9-18.
# profiles -p "SiteApp" profiles:SiteApp> add auths="com.newco.siteapp.data.modify" profiles:SiteApp> end profiles:SiteApp> exit
Pour le vérifier, l'administrateur répertorie le contenu du profil.
# profiles -p SiteApp Found profile in files repository. id=/opt/site-app/bin/site-cmd auths=com.newco.siteapp.data.modify
Une ancienne application est une commande ou un jeu de commandes. Les attributs de sécurité sont définis pour chaque commande dans un profil de droits assigné à un rôle. Un utilisateur qui prend le rôle peut exécuter l'ancienne application avec les attributs de sécurité.
Avant de commencer
Pour créer le profil de droits, vous devez vous connecter en tant qu'administrateur disposant du profil de droits Information Security (sécurité des informations) ou Rights Management (gestion des droits). Pour affecter le profil de droits, vous devez vous connecter en tant qu'administrateur disposant du profil de droits User Security (sécurité des utilisateurs). Le rôle root peut effectuer toutes les tâches de cette procédure. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
Vous pouvez ajouter les attributs de sécurité à une ancienne application de la même façon que vous le feriez pour n'importe quelle commande. Vous devez ajouter la commande avec les attributs de sécurité à un profil de droits. Pour une commande héritée, donnez-lui les attributs de sécurité euid=0 ou uid=0. Pour plus d'informations sur cette procédure, reportez-vous à la section Création d'un profil de droits.
Pour connaître la procédure à suivre, reportez-vous à la section Création d'un profil de droits.
Pour consulter un exemple, reportez-vous à l'Exemple 9-18.
Pour affecter un profil de droits à un rôle, reportez-vous à l'Exemple 9-14.
Exemple 9-22 Ajout d'attributs de sécurité à des commandes dans un script
Si une commande d'un script doit avoir le bit setuid ou setgid défini pour s'exécuter correctement, les attributs de sécurité du fichier exécutable du script et de la commande doivent être ajoutés dans un profil de droits. Ensuite, le profil de droits est affecté à un rôle, à son tour affecté à un utilisateur. Lorsque l'utilisateur prend le rôle et exécute le script, la commande s'exécute avec les attributs de sécurité.
Exemple 9-23 Recherche d'autorisations dans un script ou un programme
Pour rechercher des autorisations, vous devez écrire un test basé sur la commande auths. Pour plus d'informations sur cette commande, reportez-vous à la page de manuel auths(1).
Par exemple, la ligne suivante vérifie si l'utilisateur dispose de l'autorisation fournie comme argument $1 :
if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then echo Auth granted else echo Auth denied fi
Pour être complet, le test doit inclure une logique qui vérifie l'utilisation de caractères génériques. Par exemple, pour tester si l'utilisateur dispose de l'autorisation solaris.system.date, vous devez rechercher les chaînes suivantes :
solaris.system.date
solaris.system.*
solaris.*
Si vous écrivez un programme, utilisez la fonction getauthattr() pour effectuer un test d'autorisation.
Les processus d'un utilisateur ou d'un rôle peuvent ne pas s'exécuter avec les attributs de sécurité qui leurs sont affectés pour différentes raisons. Cette procédure aide à résoudre les échecs d'affectation d'attribut de sécurité. Plusieurs étapes sont basées sur la section Ordre de recherche pour les attributs de sécurité affectés.
Avant de commencer
Vous devez prendre le rôle root. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d'administration.
# svccfg -s name-service/switch svc:/system/name-service/switch> listprop config config application config/value_authorization astring solaris.smf.value.name-service.switch config/default astring files ldap config/host astring "files dns mdns ldap" config/netgroup astring ldap config/printer astring "user files"
Dans cette sortie, tous les services qui ne sont pas explicitement mentionnés héritent de la valeur par défaut, files ldap. Par conséquent, la recherche porte tout d'abord sur passwd (et donc user_attr), auth_attr et prof_attr dans les fichiers, puis dans LDAP.
Le démon nscd peut présenter un long intervalle de durée de vie. En redémarrant le démon, vous mettez à jour le service de noms avec les données en cours.
# svcadm restart name-service/cache
Utilisez l'attribut de sécurité en tant que valeur de la commande userattr -v. Par exemple, les commandes suivantes indiquent les attributs de sécurité affectés et le lieu où l'affectation a été effectuée pour l'utilisateur jdoe :
# userattr -v audit_flags jdoe Indicates modified system defaults user_attr: fw:no # userattr -v auths jdoe Indicates no added auths Basic Solaris User :solaris.mail.mailq,solaris.network.autoconf.read, solaris.admin.wusb.read Console User :solaris.system.shutdown,solaris.device.cdrw, solaris.device.mount.removable,solaris.smf.manage.vbiosd,solaris.smf.value.vbiosd # userattr -v defaultpriv jdoe Indicates basic user privileges only # userattr -v limitpriv jdoe Indicates default limit privileges # userattr -v lock_after_retries jdoe Indicates no automatic lockout # userattr -v pam_policy jdoe Assigned per-user PAM policy # userattr -v profiles jdoe Indicates assigned rights profiles user_attr: Audit Review,Stop # userattr roles jdoe Assigned roles user_attr : cryptomgt,infosec
La sortie indique que des indicateurs d'audit, deux profils de droits et deux rôles sont directement affectés à jdoe. Par conséquent, toutes les valeurs d'indicateur d'audit des profils de droits sont ignorées. Au moment où l'utilisateur prend un rôle, les indicateurs d'audit de ce rôle remplacent les indicateurs d'audit de l'utilisateur.
La source d'une affectation d'autorisation n'est pas importante, car les autorisations s'accumulent pour les utilisateurs. Une autorisation mal orthographiée échoue toutefois discrètement.
Par exemple, certaines commandes requièrent la réussite de uid=0 plutôt que de euid=0. De plus, les options de certaines commandes peuvent nécessiter des autorisations.
Utilisez la commande userattr, comme indiqué à l'Étape 2.
La valeur de l'attribut dans les premiers profils de droits de la liste est la valeur dans le noyau. Si cette valeur est incorrecte, modifiez-la dans ce profil de droits ou réaffectez les profils dans l'ordre correct.
Dans le cas de commandes privilégiées, vérifiez si un privilège est affecté dans le mot-clé defaultpriv ou supprimé du mot-clé limitpriv.
Si l'attribut est affecté à un rôle, l'utilisateur doit prendre le rôle pour obtenir les attributs de sécurité. Si l'attribut est affecté à plusieurs rôles, l'affectation dans le premier rôle de la liste est valide. Si cette valeur est incorrecte, affectez la valeur correcte au premier rôle de la liste ou réaffectez les rôles dans l'ordre correct.
Au lieu d'affecter un privilège directement, affectez-le à la commande qui le nécessite, ajoutez les autorisations nécessaires, placez la commande et les autorisations dans un profil de droits, et affectez le profil à l'utilisateur.
Si c'est le cas, affectez-le à l'utilisateur. Placez ce profil de droits devant les autres profils de droits incluant la commande.
Les commandes d'administration doivent être exécutées dans un shell de profil. Pour réduire les erreurs de l'utilisateur, vous pouvez affecter un shell de profil comme shell de connexion d'utilisateur. Ou bien, vous pouvez rappeler à l'utilisateur d'exécuter les commandes d'administration dans un shell de profil.
En particulier, vérifiez les valeurs des attributs defaultpriv et limitpriv de l'utilisateur.
La première valeur dans la liste des profils de droits est la valeur dans le noyau. Si cette valeur est incorrecte, modifiez-la dans ce profil de droits ou réaffectez les profils dans l'ordre correct.
En particulier, vérifiez les valeurs des attributs defaultpriv et limitpriv du profil.
Si la commande est affectée à un rôle, l'utilisateur doit prendre le rôle pour obtenir les attributs de sécurité. Si l'attribut est affecté à plusieurs rôles, l'affectation dans le premier rôle de la liste est valide. Si la valeur est incorrecte, affectez la valeur correcte au premier rôle de la liste ou réaffectez les rôles dans l'ordre correct.
Les commandes d'administration nécessitent des privilèges pour s'exécuter correctement. Les options de certaines commandes peuvent nécessiter des autorisations. La pratique recommandée consiste à affecter un profil de droits incluant la commande d'administration.
En particulier, vérifiez les valeurs des attributs defaultpriv et limitpriv du rôle.
La première valeur dans la liste des profils de droits est la valeur dans le noyau. Si cette valeur est incorrecte, modifiez-la dans ce profil de droits ou réaffectez les profils dans l'ordre correct.