Personnalisation RBAC pour votre site (tâches)

La configuration initiale de RBAC inclut la création d'utilisateurs qui peuvent endosser 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.

Procédure de 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'endosser 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 :

   • Pour les profils de droits disponibles sur votre système, utilisez 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 racine. 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.

Procédure de 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 et affecter son mot de passe initial, le profil de droits User Management (gestion des utilisateurs) doit vous être affecté. Pour affecter des attributs de sécurité au rôle, le profil de droits User Security (sécurité des utilisateurs) doit vous être affecté.

1. Endossez le rôle d'administrateur et dotez-vous des attributs de sécurité nécessaires.

   Pour plus d'informations, reportez-vous à la section Procédure d'obtention des droits d'administration.

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

   Les arguments RBAC de la commande sont les suivants :

   # roleadd [-e expire] [-f inactive] [-s shell] [-m] [-S repository] \
   [-A authorization-list] -K key=value] rolename

   -e expire

   Date d'expiration d'un rôle. Utilisez cette option pour créer des rôles temporaires.

   -f inactive

   Nombre maximal de jours autorisé entre les utilisations d'un rôle. Lorsque la valeur inactive est dépassée, le rôle ne peut pas être utilisé. La valeur par défaut est 0, aucune date d'expiration.

   -m

   Crée un répertoire personnel pour rolename à l'emplacement par défaut.

   -s shell

   Shell de connexion pour rolename. Ce shell doit être un shell de profil. Pour obtenir une liste des shells de profil, reportez-vous à la page de manuel pfexec(1).

   ---

   Astuce - Vous pouvez également répertorier les shells de profil dans le répertoire /usr/binsur votre système, comme dans ls /usr/bin/pf*sh.

   ---

   -S repository

   L'un de files ou ldap. La valeur par défaut correspond à des fichiers locaux.

   -A authorization-list

   Une ou plusieurs autorisations séparées par des virgules. Pour obtenir la liste des autorisations, reportez-vous au fichier /etc/security/auth_attr.

   -K key=value

   Paire key=value. Cette option peut être répétée. Les clés suivantes sont disponibles : audit_flags, auths, profiles, project, defaultpriv, limitpriv, lock_after_retries et roleauth. Pour plus d'informations sur les clés, leurs valeurs et les autorisations requises pour définir les valeurs, reportez-vous à la page de manuel user_attr(4).

   rolename

   Nom du nouveau rôle. Pour connaître les restrictions sur les chaînes acceptables, reportez-vous à la page de manuel roleadd(1M).

   ---

   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.

   ---

   Par exemple, la commande suivante crée un rôle d'administrateur des utilisateurs local et un répertoire personnel.

   # 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

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

   # passwd -r files useradmPassword: <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.

   ---

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

   Pour connaître la procédure, reportez-vous à la section Procédure d'attribution de rôle et à l'Exemple 9-10.

Exemple 9-7 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-8 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 personnels, leur assigner un mot de passe initial et effectuer d'autres tâches non liées à la sécurité. Le rôle usersec ne peut pas créer d'utilisateurs, mais peut modifier les mots de passe d'utilisateur et d'autres propriétés RBAC.

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

Procédure d'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 endosser le rôle.

Avant de commencer

Vous avez ajouté un rôle et lui avez attribué un mot de passe, comme indiqué à la section Procédure de création d'un rôle.

Pour modifier la plupart des attributs de sécurité d'un utilisateur, le profil de droits User Security (sécurité des utilisateurs) doit vous être affecté. Pour modifier les indicateurs d'audit d'un utilisateur, vous devez être connecté en tant que superutilisateur. Pour modifier d'autres attributs, le profil de droits User Management (gestion des utilisateurs) doit vous être affecté.

1. Endossez le rôle d'administrateur et dotez-vous des attributs de sécurité nécessaires.

   Pour plus d'informations, reportez-vous à la section Procédure d'obtention des droits d'administration.

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

   Pour connaître les options de la commande usermod, reportez-vous à la page de manuel usermod(1M) ou à la description de l'Étape 2 in Procédure de création d'un rôle.

3. Pour appliquer les modifications apportées, redémarrez le démon nscd.

   # svcadm restart system/name-service-cache

Exemple 9-10 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. L'administrateur redémarre le démon nscd pour appliquer l'affectation.

# 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
# svcadm restart system/name-service-cache

L'utilisateur avec l'UID 1111 se connecte, puis endosse 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).

Procédure d'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 endosse 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, le profil de droits Audit Configuration (configuration d'audit) doit vous avoir été attribué. Pour activer ou actualiser le service d'audit, vous devez disposer du profil de droits Audit Control (contrôle d'audit).

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. Endossez le rôle d'administrateur et dotez-vous des attributs de sécurité nécessaires.

   Pour plus d'informations, reportez-vous à la section Procédure d'obtention des droits d'administration.

3. 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-25.

4. Activez ou actualisez le service d'audit.

   # audit -s

Procédure de création ou de modification 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.

La façon la plus simple de créer un nouveau profil de droits est de copier et modifier un profil de droits existant.

Avant de commencer

Pour créer ou modifier un profil de droits, vous devez disposer du profil de droits File Security (sécurité des fichiers).

1. Endossez le rôle d'administrateur et dotez-vous des attributs de sécurité nécessaires.

   Pour plus d'informations, reportez-vous à la section Procédure d'obtention des droits d'administration.

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

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

   Vous êtes invité à saisir un nouveau nom. Le contenu du profil de droits existant est dupliqué dans le nouveau profil.

3. Continuez à modifier le nouveau profil de droits.

   Ajoutez ou supprimez des profils de droits, des autorisations et d'autres attributs de sécurité, comme indiqué dans les exemples suivants.

Exemple 9-11 Création d'un nouveau profil de droits à partir d'un profil existant

Dans cet exemple, l'administrateur personnalise le profil de droits Console User (utilisateur de la console) dans le référentiel LDAP.

# profiles -S ldap Console User
New name: ExampleCo Console User
ExampleCo Console User >
Description > Manage MyCompany Systems as the Console User
Help > ExCoConsUser.html

L'administrateur définit l'attribut roleauth pour ce profil de droits.

roleauth=yes

Exemple 9-12 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 privilège de base de tous les utilisateurs auxquels le profil de droits SunRayUser est affecté. Ils sont dans l'impossibilité d'utiliser le privilège proc_session. C'est-à-dire que ces utilisateurs ne peuvent pas examiner les processus à l'extérieur de la session actuelle de l'utilisateur.

$ profiles -K defaultpriv=basic,!proc_session SunRayUser

Exemple 9-13 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 un privilège limite de tous les utilisateurs auxquels le profil de droits SunRayUser est affecté. Cette suppression empêche les utilisateurs d'afficher les processus d'autres utilisateurs.

$ profiles -K limitpriv=all,!proc_session SunRayUser

Exemple 9-14 Ajout de privilèges à une commande

Dans cet exemple, l'administrateur de la sécurité ajoute des privilèges à une application dans un profil de droits. 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 Procédure de 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.

Procédure d'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. Le profil de droits est ensuite inclus dans un rôle. Un utilisateur qui endosse 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, le profil de droit Information Security (sécurité des informations) ou Rights Management (gestion des droits) doit vous être affecté. Pour affecter le profil de droits, le profil de droits User Security (sécurité des utilisateurs) doit vous être affecté.

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 Procédure de création ou de modification d'un profil de droits.

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

      Pour plus d'informations sur les étapes à suivre, reportez-vous à la section Procédure de création ou de modification 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-14.

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

Exemple 9-15 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 inclus dans un rôle et le rôle est assigné à un utilisateur. Lorsque l'utilisateur endosse le rôle et exécute le script, la commande s'exécute avec les attributs de sécurité.

Exemple 9-16 Recherche d'autorisations dans un script ou un programme

Pour avoir un script pour les autorisations, vous devez ajouter 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 plus complet, le test doit inclure une logique vérifiant la présence d'autres autorisations utilisant des 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.

Procédure de 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.

• L'attribut de sécurité est mal orthographié. Les autorisations mal orthographiées échouent en silence.

• L'utilisateur ou le rôle n'utilise pas le service de noms qui inclut les affectations.

• L'affectation que vous êtes en droit d'attendre n'est pas la première affectation de cet attribut.

  L'ordre dans lequel les attributs de sécurité d'un utilisateur ou d'un rôle sont recherchés, puis affectés lors de l'authentification détermine les affectations correctes, sauf pour les autorisations. Lors de la recherche, les autorisations qui sont affectées à l'utilisateur ou au rôle s'accumulent. En revanche, l'affectation de privilèges et l'affectation d'attributs de sécurité dans des profils de droits dépendent de la recherche effectuée. La première affectation est retenue, les suivantes sont ignorées.

• La commande n'est pas exécutée dans un shell de profil.

Avant de commencer

Vous devez être dans le rôle root.

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

2. Déterminez le lieu d'affectation d'un attribut de sécurité.

   Utilisez l'attribut de sécurité comme valeur pour 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 Modifications to the system defaults
   user_attr: fw:no
   # userattr -v auths jdoe Assigned authorizations
   solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,
   solaris.mail.mailq,solaris.profmgr.read,solaris.smf.manage.audit,
   solaris.smf.value.audit
   # userattr -v audit_flags jdoe Modifications to audit preselection mask
   # userattr -v auths jdoe Assigned authorizations
   # userattr -v defaultpriv jdoe Modifications to basic user privileges
   # userattr -v limitpriv jdoe Modifications to limit privileges 
   # userattr -v lock_after_retries jdoe Automatic lockout attribute
   # userattr -v profiles jdoe Assigned rights profiles
   user_attr: Audit Review,Stop
   # userattr roles jdoe Assigned roles
   user_attr : cryptomgt,infosec

3. Pour les profils de droits que vous avez créés, vérifiez que vous avez affecté les attributs de sécurité appropriés à la commande.

   Par exemple, certaines commandes requièrent uid=0 plutôt que euid=0 pour s'exécuter correctement. Certains aspects de certaines commandes peuvent requérir des autorisations.

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

   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 que l'utilisateur peut utiliser. Si cette valeur est incorrecte, modifiez-la dans ce profil de droits, ou réorganisez la liste des profils.

         Dans le cas de commandes privilégiées, vérifiez si un privilège est affecté dans le mot-clé defaultpriv. Cette affectation s'ajoute aux privilèges sur une commande particulière.

      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 endosser 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éorganisez l'affectation de rôle.

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

   ---

   Remarque - Certains aspects de certaines commandes peuvent requérir une autorisation. La pratique recommandée consiste à affecter un profil de droits incluant la commande d'administration, au lieu d'affecter un privilège directement.

   ---

   Passez en revue les profils de droits incluant la commande d'administration. Si un profil de droits incluant les autorisations existe, affectez le profil de droits à l'utilisateur, et pas simplement les privilèges. Placez ce profil de droits devant les autres profils de droits incluant la commande.

6. 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 que l'utilisateur peut utiliser. Si cette valeur est incorrecte, modifiez-la dans ce profil de droits, ou réorganisez la liste des profils.

         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 endosser 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éorganisez l'affectation de rôle.

7. 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. Certains aspects de certaines commandes peuvent requérir une autorisation. 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 que l'utilisateur peut utiliser. Si cette valeur est incorrecte, modifiez-la dans ce profil de droits, ou réorganisez la liste des profils.