Rôles, droits, privilèges et autorisations

Les informations suivantes décrivent le fonctionnement des rôles, droits et privilèges sous Oracle Solaris 11 :

• Attribution ou délégation d'autorisations : Oracle Solaris fournit des autorisations pour déléguer des droits administratifs spécifiques à certains utilisateurs et rôles, afin de mettre en oeuvre une séparation des tâches. Sous Oracle Solaris 10, les autorisations se terminant par .grant sont requises pour déléguer une autorisation à un autre utilisateur. Sous Oracle Solaris 11, deux nouveaux suffixes sont utilisés : .assign et .delegate. Par exemple : solaris.profile.assign et solaris.profile.delegate. Le premier suffixe accorde le droit de déléguer tout profil de droits à tout utilisateur ou rôle. Le second suffixe est plus restrictif, car seuls les profils de droits déjà assignés à l'utilisateur actuel peuvent être délégués. Comme solaris.* est assigné au rôle root, ce rôle peut assigner toute autorisation à tout utilisateur ou rôle. Par mesure de sécurité, aucune autorisation se terminant par .assign n'est incluse dans un profil par défaut.

• Profil de droits Media Restore (restauration des médias) : ce profil de droits et cet ensemble d'autorisations permettent d'escalader les privilèges d'un compte sans rôle root. Ce profil existe, mais il ne fait partie d'aucun autre profil de droits. Comme ce profil de droits Media Restore permet d'accéder à l'ensemble du système de fichiers racine, son utilisation peut escalader des privilèges. Des fichiers délibérément modifiés ou des médias de substitution peuvent être restaurés. Par défaut, le rôle root inclut ce profil de droits.

• Suppression du profil Primary Administrator (administrateur principal) : l'utilisateur initial créé lors de l'installation reçoit les rôles et droits suivants :

  • Rôle root

  • Profil de droits System Administrator (administrateur système)

  • Accès à la commande sudo pour toutes les commandes exécutées en tant que root

• Authentification des rôles : vous pouvez spécifier user ou role pour le mot-clé roleauth. Reportez-vous à la page de manuel user_attr(4).

• Root en tant que rôle : root est désormais un rôle par défaut, donc non anonyme, et qui ne peut pas se connecter à distance à un système. Pour plus d'informations sur la transformation du rôle root en utilisateur, reportez-vous à la section Procédure de modification du rôle root en utilisateur du manuel Administration d’Oracle Solaris : services de sécurité.

• Privilèges de base d'Oracle Solaris 11 (entre autres) :

  • file_read

  • file_write

  • net_access

• Versions de shells de profils pour les shells standard : chaque shell standard dispose désormais de sa propre version de profil. Les shells de profils suivants sont disponibles :

  • pfbash

  • pfcsh

  • pfksh

  • pfksh93

  • pfrksh93

  • pfsh

  • pftcsh

  • pfzsh

  Reportez-vous à la page de manuel pfexec(1).

• Profils de droits : les bases de données user_attr, prof_attr et exec_attr sont désormais en lecture seule. Ces bases de données de fichiers locaux sont assemblées à partir de fragments se trouvant dans /etc/user_attr.d, /etc/security/prof_attr.d et /etc/security/exec_attr.d. Les fragments de fichiers ne sont pas fusionnés en une seule version du fichier, ils restent sous forme de fragments. Cette modification permet aux packages de fournir des profils RBAC (Role Based Access Control, contrôle d'accès basé sur les rôles) complets ou partiels. Les entrées ajoutées au référentiel de fichiers locaux à l'aide des commandes useradd et profiles sont ajoutées au fichier local-entries du répertoire de fragments. Pour ajouter ou modifier un profil, exécutez la commande profiles. Reportez-vous à la section Procédure de création ou de modification d’un profil de droits du manuel Administration d’Oracle Solaris : services de sécurité.

• Profil d'arrêt de droits : ce profil permet aux administrateurs de créer des comptes limités. Reportez-vous à la section Profils de droits RBAC du manuel Administration d’Oracle Solaris : services de sécurité.

• Commande pfsh script : cette commande fonctionne désormais comme la commande pfsh -c script. Auparavant, les commandes d'un script ne pouvaient pas tirer parti de la fonctionnalité RBAC, sauf si la première ligne du script spécifiait un shell de profil. Si vous souhaitiez utiliser la fonctionnalité RBAC, vous deviez modifier les scripts ; cela est désormais inutile, car le programme appelant du script (ou un ancêtre au sein d'une session) peut spécifier un shell de profil.

• Commande pfexec : cette commande n'est plus setuid root. Le nouvel attribut de processus PF_PFEXEC est défini lorsque la commande pfexec ou un shell de profil sont exécutés. Ensuite, le noyau définit les privilèges appropriés sur exec. Cette implémentation assure que les sous-shells sont habilités ou limités, selon le cas.

  Lorsque le noyau traite une commande exec(2), il traite setuid to root différemment. Notez que toute commande setgid ou setuid pour un autre uid que root fonctionne comme auparavant. Le noyau recherche désormais une entrée dans le profil RBAC Forced Privilege dans exec_attr(4) pour déterminer les privilèges sous lesquels le programme doit s'exécuter. Au lieu de démarrer avec l'uid root et tous les privilèges, le programme s'exécute avec l'uid actuel et uniquement les privilèges supplémentaires que le profil d'exécution RBAC Forced Privilege a assignés à ce nom de chemin.

Affichage de vos privilèges

Lorsque des privilèges sont assignés directement à un utilisateur, ces privilèges sont en fait présents dans chaque shell. Lorsque les privilèges ne lui sont pas directement attribués, l'utilisateur doit ouvrir un shell de profil. Par exemple, lorsque les commandes ayant des privilèges attribués se trouvent dans un profil de droits répertorié dans la liste de profils de droits de l'utilisateur, l'utilisateur doit exécuter la commande dans un shell de profil.

Pour afficher des privilèges en ligne, reportez-vous à la page de manuel privileges(5). Le format de privilège qui s'affiche est utilisé par les développeurs.

$ man privileges
Standards, Environments, and Macros                 privileges(5)

NAME
     privileges - process privilege model
...
     The defined privileges are:

     PRIV_CONTRACT_EVENT

         Allow a process to request reliable delivery  of  events
         to an event endpoint.

         Allow a process to include events in the critical  event
         set  term  of  a  template  which  could be generated in
         volume by the user.
...

Exemple 9-1 Affichage de privilèges assignés directement

Si des privilèges vous ont été attribués directement, votre jeu de base contient plus que le jeu de base par défaut. Dans l'exemple suivant, l'utilisateur a toujours accès au privilège proc_clock_highres.

$ /usr/bin/whoami
jdoe
$ ppriv -v $$
1800:   pfksh
flags = <none>
        E: file_link_any,…,proc_clock_highres,proc_session
        I: file_link_any,…,proc_clock_highres,proc_session
        P: file_link_any,…,proc_clock_highres,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time
$ ppriv -vl proc_clock_highres
        Allows a process to use high resolution timers.