Personnalisation RBAC pour votre site (tâches)

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.

Configuration initiale RBAC (liste des tâches)

Utilisez la liste des tâches ci-dessous pour planifier et implémenter initialement RBAC sur votre site. Certaines tâches sont triées.

Planification de votre implémentation RBAC

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.

1. Découvrez les concepts RBAC de base.

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

2. Examinez votre stratégie de sécurité.

   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.

3. Décidez du degré de nécessité de RBAC pour votre organisation.

   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.

4. Déterminez les rôles appropriés pour votre organisation.

   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.

5. Déterminez si l'un des rôles ou des profils de droits supplémentaires sont appropriés pour votre organisation.

   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.

   1. Déterminez les commandes nécessaires pour la nouvelle tâche.
   2. Choisissez le profil de droits approprié pour cette tâche.

      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.

      ---

   3. Déterminez le rôle approprié pour ce profil de droits.

      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.

6. Déterminez les utilisateurs devant être affectés aux rôles.

   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.

Création d'un rôle

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.

1. Pour créer un rôle, utilisez la commande roleadd.

   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

2. Créez le mot de passe initial du rôle.

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

   ---

3. Pour affecter un rôle à un utilisateur, exécutez la commande usermod.

   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

Attribution de rôle

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.

• Attribuez le rôle à un utilisateur.

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

Audit des rôles

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.

1. Incluez l'audit des rôles dans votre plan d'audit.

   Pour obtenir des informations de planification, reportez-vous au Chapitre 27, Planification de l'audit.

2. Présélectionnez l'une des classes as, ex, ps, ou ua.
   • Si le service d'audit est activé, passez en revue les classes présélectionnées.

     # 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

   • Si l'audit n'est pas encore activé, présélectionnez une classe qui audite les actions du rôle.

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

3. Activez ou actualisez le service d'audit.

   # audit -s

Création d'un profil de droits

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.

1. Créez un profil de droits.

   # profiles -p [-S repository] profile-name

   Vous êtes invité à saisir une description.

2. Ajoutez du contenu au profil de droits.

   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.

Clonage et modification d'un profil de droits système

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.

1. Créez un nouveau profil de droits à partir d'un profil existant.

   # profiles -p [-S repository] existing-profile-name

   • Pour améliorer un profil de droits existant, créez un profil.

     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.

   • Pour supprimer du contenu d'un profil de droits existant, clonez ce dernier.

     Ensuite, renommez-le et apportez les modifications. Pour consulter un exemple, reportez-vous à l'Exemple 9-20.

2. Continuez à modifier le nouveau profil de droits.

   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.

Création d'une autorisation

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.

1. (Facultatif) Créez le fichier d'aide de la nouvelle autorisation.

   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>

2. Créez l'autorisation.

   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

Ajout de propriétés RBAC aux anciennes applications

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.

1. Ajoutez les attributs de sécurité aux commandes qui implémentent l'ancienne application.

   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.

   1. Créez un nouveau profil de droits pour votre ancienne application.

      Pour connaître la procédure à suivre, reportez-vous à la section Création d'un profil de droits.

   2. Ajoutez les commandes avec les attributs de sécurité requis.

      Pour consulter un exemple, reportez-vous à l'Exemple 9-18.

2. Incluez le profil de droits dans la liste des profils d'un rôle.

   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.

Dépannage de RBAC et de l'affectation de privilèges

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.

1. Vérifiez et redémarrez le service de noms.
   1. Vérifiez que les affectations de sécurité pour l'utilisateur ou le rôle sont dans le service de noms activé sur le système.

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

   2. Redémarrez le cache du service de noms, svc:/system/name-service/cache.

      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

2. Déterminez à quel emplacement un attribut de sécurité a été affecté à l'utilisateur.

   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.

3. Vérifiez que les autorisations affectées sont orthographiées correctement.

   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.

4. Pour les profils de droits que vous avez créés, vérifiez que vous avez affecté les attributs de sécurité appropriés aux commandes dans ce profil.

   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.

5. Vérifiez les points suivants si des attributs de sécurité ne sont pas disponibles pour un utilisateur.
   1. Vérifiez si les attributs de sécurité sont directement affectés à l'utilisateur.

      Utilisez la commande userattr, comme indiqué à l'Étape 2.

   2. Si les attributs de sécurité ne sont pas directement affectés, vérifiez les profils de droits qui sont directement affectés à l'utilisateur.
      1. Dans l'ordre, recherchez l'affectation de l'attribut de sécurité dans la liste des profils de droits.

         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.

      2. Si aucune affectation d'attribut n'est répertoriée, vérifiez les rôles affectés à l'utilisateur.

         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.

6. Si vous avez assigné un privilège directement à un utilisateur ou un rôle, vérifiez si l'échec d'une commande requiert des autorisations pour s'exécuter correctement.
   1. Vérifiez si une option de la commande nécessite une autorisation.

      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.

   2. Vérifiez si un profil de droits incluant l'autorisation requise existe.

      Si c'est le cas, affectez-le à l'utilisateur. Placez ce profil de droits devant les autres profils de droits incluant la commande.

7. Vérifiez les points suivants si une commande continue d'échouer pour un utilisateur.
   1. Vérifiez que l'utilisateur exécute la commande dans un shell de profil.

      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.

   2. Vérifiez si des attributs de sécurité directement affectés à l'utilisateur empêchent la commande de s'exécuter correctement.

      En particulier, vérifiez les valeurs des attributs defaultpriv et limitpriv de l'utilisateur.

   3. Déterminez le profil de droits ou le rôle qui inclut la commande.
      1. Dans l'ordre, recherchez la commande avec des attributs de sécurité dans la liste des profils de droits.

         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.

      2. Si aucune affectation d'attribut n'est répertoriée, vérifiez les rôles affectés à l'utilisateur.

         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.

8. Vérifiez les points suivants si une commande échoue pour un rôle.

   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.

   1. Vérifiez si des attributs de sécurité directement affectés au rôle empêchent la commande de s'exécuter correctement.

      En particulier, vérifiez les valeurs des attributs defaultpriv et limitpriv du rôle.

   2. Dans l'ordre, recherchez la commande avec des attributs de sécurité dans la liste des profils de droits.

      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.